Understanding Integration Patterns in Event-Driven Architecture
A quick introduction to event-driven architectures, its main characteristics, and common integration patterns.
- You can compare timestamps of input events with that of the latest event processed for the same scope (for example, the same customer, order, or product). If the event is older than the last one processed for the same scope, you can either skip the event or handle out-of-order processing, depending on your use case.
- Another approach is to store a unique index of processed events so that you can check if each input event has already been processed and skip it. To avoid the index to become too big over time, you should define an acceptable time window for which you should check event uniqueness. Depending on your use case, that can be five minutes, a day, or longer. After that time window has passed, events can be automatically removed from the index.
"The appropriate level of coupling depends on the level of control you have over the endpoints." – Gregor Hohpe, Enterprise Integration Patterns
NewOrder
event) to a payment system. The payment system can then send messages to the delivery system in case the payment is correct (a PaidOrder
event), or to a fraud management system if something suspicious is found during the payment (a PossibleFraud
event).- If not enough information is sent in the event payload, the receiver might need to do synchronous request-response calls to get the missing information it needs to run its business logic.
- If too much information is included, the receiver might use a subset of the data that at some point in the future will need to have its format or values updated. Data format changes can have a cascading effect on all consuming services. It is therefore a good practice to decrease coupling by restricting information included in the events to what is necessary (often defined "key data").
Any opinions in this post are those of the individual author and may not reflect the opinions of AWS.