EDA Architecture Discussion
5 exercises — practise the language of architecture trade-off discussions: arguing for EDA, justifying eventual consistency, evaluating schema evolution strategy, assessing migration candidates, and diagnosing cascading failures.
0 / 5 completed
1 / 5
In a system design review, a colleague asks: "Why should we consider moving from a REST-based integration to an event-driven architecture? What's the core architectural argument?"
Which answer presents the strongest EDA argument?
Decoupling is the foundational EDA argument — always lead with this in architecture discussions.
REST integration — coupling dimensions:
① Temporal coupling: the downstream service must be available when you call it. If it's down, your request fails.
② Behavioural coupling: you must know the downstream API's endpoint, schema, and authentication.
③ Scaling coupling: high load on your service → immediate high load on the downstream service.
EDA — decoupling benefits:
① Temporal decoupling: publisher and consumer can be offline at different times. Events are stored and processed when the consumer is ready.
② Behavioural decoupling: the publisher doesn't know who consumes its events. New consumers can be added without touching the publisher.
③ Scale decoupling: consumers scale independently; a traffic spike on the producer side doesn't directly flood consumers.
When to bring up REST instead:
• When you need an immediate response to a query (EDA is async; REST is sync)
• When the operation is a request for data, not a notification of a state change
• When simplicity is more important than scalability
Key phrases for architecture discussions:
• "This reduces temporal coupling between the services"
• "The publisher doesn't need to know about its consumers"
• "We get natural backpressure handling through the queue"
REST integration — coupling dimensions:
① Temporal coupling: the downstream service must be available when you call it. If it's down, your request fails.
② Behavioural coupling: you must know the downstream API's endpoint, schema, and authentication.
③ Scaling coupling: high load on your service → immediate high load on the downstream service.
EDA — decoupling benefits:
① Temporal decoupling: publisher and consumer can be offline at different times. Events are stored and processed when the consumer is ready.
② Behavioural decoupling: the publisher doesn't know who consumes its events. New consumers can be added without touching the publisher.
③ Scale decoupling: consumers scale independently; a traffic spike on the producer side doesn't directly flood consumers.
When to bring up REST instead:
• When you need an immediate response to a query (EDA is async; REST is sync)
• When the operation is a request for data, not a notification of a state change
• When simplicity is more important than scalability
Key phrases for architecture discussions:
• "This reduces temporal coupling between the services"
• "The publisher doesn't need to know about its consumers"
• "We get natural backpressure handling through the queue"