Delivered Is Not Done: Event-Driven Integration on AWS for Manufacturers

What event-driven integration means here

An event is a record that something changed. Amazon describes an EventBridge event as a JSON object sent to an event bus, and says that in event-driven architecture it often represents an indicator of a change in a resource or environment. For a manufacturer, the business version is a statement such as "sales order confirmed," "work order completed," "pallet received," or "shipment tendered."

EventBridge uses an event bus as the router. A Classic event bus is a router that receives events and delivers them to zero or more destinations, or targets. Amazon notes that you can use a bus as a broker between different workloads, services, or systems.

The bus alone does not define a handoff. Each cross-system handoff still needs a business definition that the manufacturer must decide. For every one, define:

• the business event and what triggers it;
• the authoritative record, meaning which system's data wins if two disagree;
• an event identifier that stays the same across retries;
• the producer that emits it and the consumer that acts on it;
• the acknowledgement that shows the consumer finished its business step, not only that it received the message.

These are design decisions, not features of a service. The AWS material describes the mechanics of routing and queuing; it does not decide which of your systems owns an order or an inventory balance.

How the pieces move an event

In EventBridge, a rule receives incoming events and sends them to targets. A rule can match on an event pattern, which contains one or more filters, or run on a schedule. Amazon states that those filters can match on event metadata, event data, and event content. A manufacturer could use that to separate shipment events from other traffic, though the routing design is its own decision. Each rule applies to its own bus, and Amazon states that a single rule can send an event to up to five targets.

Targets can include AWS services and outside endpoints. Amazon says API destinations let you route events between AWS services, integrated SaaS applications, and your applications outside of AWS, which is how an event could reach a system that is not running on AWS.

Queues add a different property. In FIFO queues, Amazon SQS enforces a 5-minute deduplication window. If a producer retries after that window, Amazon SQS treats it as a new message, potentially creating duplicates. On the consumer side, if a consumer fails to process a message before the visibility timeout expires, another consumer may receive and process it. Amazon's guidance is to adjust the timeout to your processing time, extend it with the ChangeMessageVisibility API while work is still in progress, and send a message that repeatedly fails to a dead-letter queue (DLQ) instead of allowing it to be reprocessed indefinitely.

Those statements describe transport behavior. They are the reason a delivered message cannot be treated as completed work.

Delivery, processing, retry, replay, and reconciliation are different things

Keep them apart:

• Transport delivery: the bus or queue handed the message to a consumer.
• Business processing: the consumer changed its own record correctly, for example created the pick task or posted the receipt.
• Retry: the same event is attempted again after a failure or timeout.

EventBridge also lets you archive and replay events. Amazon says you can archive, or save, events and then replay them at a later time from the archive, and lists testing and adding more durability to your event-driven applications among the uses. A replay re-presents events to consumers that may already have acted on them, so the manufacturer must decide how consumers treat a repeat.

That is why the event identifier from the earlier list matters. SQS documents two ways duplicates can arise: a producer retries a SendMessage request after 5 minutes, and a consumer fails to process a message before the visibility timeout expires. Designing that recognition into the consumer's business logic is a task for the manufacturer or its integrator.

Finally, reconciliation is a separate control from messaging: comparing the records in two systems on a schedule and resolving differences. The AWS documentation does not define it for you, so assign it a named owner and a cadence rather than assuming the messaging layer covers it.

Use cases across order, production, inventory, shipment, and exceptions

The pattern applies wherever a record crosses a boundary. Consider these as illustrative designs, not a description of any particular plant:

• Order to production. When the ERP confirms an order, an event could notify the MES so a work order can be created. The ERP might remain the authoritative record for the order, and the MES for execution status. The acknowledgement the ERP waits for should reflect that the work order exists, not that the message arrived.
• Production to inventory. A completion event from the MES could prompt the ERP or WMS to recognize finished goods. A consumer that can recognize a repeated event identifier prevents a replayed completion from adding the same quantity twice.
• Inventory to shipment. A WMS pick confirmation could prompt a TMS to book a carrier. If booking fails, the failure should land somewhere a person owns.
• Exceptions. Delayed or rejected handoffs are themselves events that need routing and a responsible owner.

Two AWS documents describe related examples in manufacturing contexts. One AWS supply chain architecture example describes [[S1|Amazon EventBridge orchestrat[ing] workflows between warehouse management systems]], with Amazon API Gateway and AWS AppSync to connect various warehouse systems and external applications. Another AWS solution describes the nightly synchronization of on-premises ERP, MRP, and HR databases in addition to near real-time inbound streaming of production events, which illustrates that a single design can mix scheduled and event-based exchange.

Amazon also frames the value of connecting systems that historically did not exchange data. Its MES guidance says that, traditionally, systems and applications within manufacturing either don't communicate or communicate rigidly based on hierarchy. Event-driven integration is one way to loosen that, but the AWS material shows no specific outcome for a given manufacturer, and none should be assumed.

Designing exception queues, ownership, and recovery

A failed handoff needs a place to go and a person to look at it. Amazon's SQS outage-recovery guidance says: If a message repeatedly fails to process, route it to a dead-letter queue (DLQ) instead of allowing it to be reprocessed indefinitely. What the manufacturer adds is the operating discipline around that queue:

• Decide how many attempts a message gets before it moves to the DLQ, and how long it may wait.
• Name an owner for each DLQ by handoff, so an order-to-production failure and a shipment-booking failure do not land in a shared pile nobody reads.
• Alert on queue depth or age so a stalled handoff becomes visible. AWS describes configuring alerts in CloudWatch or through Amazon SNS to notify administrators of critical events, and cites CloudWatch and AWS X-Ray for monitoring and troubleshooting capabilities.
• Decide, per exception type, whether recovery means fixing data and replaying, correcting the record manually, or escalating to a business owner.

Bound the queues. The point of a DLQ is to separate messages that need a human decision from the normal flow, so someone must be assigned to make that decision.

Synchronous, scheduled, or event-driven: choosing by requirement

Event-driven is not automatically the right answer. Compare the three patterns against the requirements that actually constrain the handoff:

• Ordering. If events must be applied in strict sequence, confirm what the chosen service guarantees before committing to it.
• Latency. Ask whether the caller needs an answer before it proceeds, or can continue and be told later.
• Volume. Ask whether the exchange is a steady stream of small changes or a large periodic transfer.
• Audit. Ask which pattern leaves the record you need: who sent what, when, and what the consumer did with it.
• Operational support. More moving parts mean more to monitor and more to staff.

These are tradeoffs to assess for your own environment. The AWS material does not rank one pattern above another, and a mixed design is possible: events for status changes, scheduled exchange for bulk reference data, and synchronous calls where an immediate answer is required.

Limits worth stating plainly

The documented services have boundaries. EventBridge limits rules per event bus by default, with Amazon stating that you can configure up to 300 rules per event bus and that the quota can be raised through Service Quotas. Amazon states that each rule is defined for a specific event bus, and only apply to events on that event bus. For SQS, Amazon SQS has a deduplication interval of 5 minutes, and retrying after that interval can introduce duplicate messages into the queue.

Questions to answer before building

A manufacturer can use these as a working checklist when scoping a handoff:

1. What is the business event, and which system's record is authoritative? Write it down for each crossing point before choosing a service.
2. What identifier makes the event unique across retries and replays? Confirm each consumer can detect and ignore a repeat.
3. What does the producer treat as an acknowledgement? Make it reflect completed business work, not message receipt.
4. What happens when a consumer fails repeatedly? Identify the DLQ, its owner, the alert, and the recovery decision.
5. Which pattern fits ordering, latency, volume, audit, and support needs? Do not default to events where a scheduled or synchronous exchange is simpler and sufficient.
6. How will the two systems be compared, by whom, and how often?
7. Who is accountable when a handoff fails? The source of a signal, the steward of a record, and the authority to decide on recovery may be different people; define each.

The short version for an executive: a message that arrives is evidence of transport, not of finished work. AWS provides routing, queuing, replay, and monitoring components. The business definitions, duplicate handling in consumers, exception ownership, and system comparison are the parts the manufacturer has to design and govern, and they determine whether the customer promise holds when something goes wrong.