Choose integration contracts from failure semantics

Learning objective

Choose synchronous APIs versus asynchronous events or data synchronization by failure and consistency requirements

Core idea

Choose the interaction from what the consumer must know. A synchronous API can return a result during the request. An asynchronous event lets processing happen independently of the producer’s request. Data synchronization gives the consumer a local representation that can lag the source. These patterns offer different evidence of completion and different recovery obligations.

“Reliable” is insufficient as a requirement. State whether the caller needs an authoritative decision now, whether a delayed result is acceptable, whether consumers can tolerate duplicates, and how stale local data may be. Also state what happens when the request times out after a write might have committed. Without those answers, choosing a queue instead of an API merely moves the uncertainty.

The authenticated adapter belongs to 2.3.1, and the detailed event-service choice belongs to 2.3.4. This lesson selects the contract before selecting the transport.

How it works

Use a synchronous API for an immediate decision

A synchronous call fits when the caller cannot proceed without a result from the owning service. For example, an agent proposing an inventory reservation must obtain the authoritative reservation outcome before telling the customer that stock is secured. A stale inventory projection is useful context, but it cannot substitute for that decision.

With API Gateway HTTP APIs, the maximum integration timeout is 30 seconds. Set the application deadline within the caller’s total budget rather than spending the entire budget on one dependency. If processing cannot complete within the relevant deadline, change the interaction to acceptance plus eventual status instead of claiming that a longer Lambda execution extends the HTTP deadline.

A timeout is an observation about the caller’s wait, not proof that the backend rolled back. For consequential writes, carry a stable operation identifier and provide a way to look up its outcome. These are business-interface requirements you implement; API Gateway does not add a distributed transaction to an enterprise API. See 2.3.1 for the adapter’s handling of uncertain commits.

Use asynchronous delivery for independent progress

Events fit when the producer can continue after the hand-off and consumers can act later. Separate a command asking for work from an event recording an established fact. “Reservation requested” does not establish “reservation committed.” Consumers should react to the meaning carried by the event, not assume every message describes completed business work.

A durable queue can buffer work during an outage, but each boundary has its own retry behavior. Lambda SQS event source mappings poll messages and invoke the worker synchronously with a batch. Successful processing causes deletion; failure leaves messages available again after the visibility timeout. Event source mappings process events at least once, so idempotency remains necessary.

Lambda asynchronous invocation uses a different mechanism: Lambda manages its own asynchronous event queue. By default, function errors receive two additional attempts. Throttling and system errors are retried for up to six hours by default. Duplicate delivery remains possible even without a function error. Configure a dead-letter queue or an on-failure destination to retain evidence of discarded or failed work rather than silently treating accepted invocation as successful processing.

For EventBridge Classic rules and targets, retriable delivery failures receive up to 185 attempts over 24 hours by default. Configure a target dead-letter queue for exhausted delivery. This is delivery to a target, not a guarantee that a downstream business transaction completes. These defaults describe Classic rule targets; they are not universal EventBridge settings. The Custom Event Bus subscriber model has its own retry configuration.

Publication and database commit are another boundary. If the source commits a transaction but cannot publish its event, consumers can miss the change. If it publishes first and the commit fails, they can observe a fact that never happened. Use a source-owned publication design that makes this gap recoverable, such as recording pending publication with the transaction and reconciling it, or capturing committed changes from database logs with AWS Database Migration Service (AWS DMS).

Do not label that design atomic without checking its actual transactional boundary. Delivery retries cannot repair an event the producer never emitted. A recovery process must compare authoritative operations with publication records and identify missing work.

Use synchronization for a local read representation

Synchronization fits a local read projection when delayed source visibility is acceptable; its freshness must be measured rather than assumed, and DMS CDC has no latency SLA. See 2.3.5 for CDC and DataSync mechanics.

A successfully transferred dataset is still not necessarily a ready retrieval index. Transformation, deletion handling, embedding, and indexing have their own completion state. Keep source synchronization separate from the vector reconciliation covered in 1.4.11. When a question requires stronger freshness than the projection can demonstrate, retrieve the authoritative result through the synchronous service or decline to make the consequential claim.

Key distinctions and trade-offs

The patterns answer different questions:

Asynchronous delivery improves failure isolation but adds state for pending, failed, and completed work. Synchronization reduces dependency calls but introduces stale reads. A synchronous authoritative operation limits stale-decision risk but couples the caller to service availability. Combine patterns when different decisions require different guarantees.

Architecture / decision scenario

A procurement assistant reads supplier documentation, requests a purchase reservation, and notifies downstream teams. A synchronized knowledge projection supports document search; it has an explicit source watermark and an independent index-ready watermark. File shares arrive through DataSync, while database changes use DMS CDC. The assistant treats both as potentially lagging.

The purchase reservation uses the owning service’s synchronous API because the user needs a committed result. A timeout triggers lookup by the operation identifier. Once the reservation is confirmed, the source publishes a reservation-committed event for billing and reporting. Those consumers can recover independently and tolerate duplicate delivery.

If the knowledge projection is delayed, the assistant can still search it with a stated freshness policy. If the reservation service is unavailable, it cannot replace authorization and inventory checks with model reasoning over the projection. The architecture uses all three patterns because search evidence, business commitment, and downstream propagation have different consistency requirements.

Common exam traps

• Treating an accepted event as a completed business transaction.
• Assuming a synchronous timeout means no write occurred.
• Using event retries to solve a database-to-publication gap.
• Applying Classic EventBridge retry defaults to every bus model.
• Calling DMS CDC instantaneous or SLA-backed replication.
• Treating a transferred source snapshot as a completed retrieval index.

What to remember

Choose synchronous APIs for authoritative decisions within a request deadline, events for independent processing, and synchronization for local data with measured freshness. Identify the acknowledgment boundary and the recovery owner for every hop. A mixed architecture is appropriate when the workflow contains different kinds of decisions.

Knowledge check

References

• AWS, Quotas for configuring and running an HTTP API in API Gateway
• AWS, Using Lambda with Amazon SQS
• AWS, How Lambda handles errors and retries with asynchronous invocation
• AWS, How EventBridge retries delivering events
• AWS, Creating tasks for ongoing replication using AWS DMS