What is the Event-Driven Architecture pattern and how does it differ from synchronous request/response?

Event-Driven Architecture (EDA) structures communication around events — immutable records of something that has happened. A producer emits an event to a broker and moves on without knowing or caring who consumes it. Consumers subscribe to events and react asynchronously and independently. No party waits for another.

In synchronous request/response, the caller blocks until the called service returns a result. This creates three forms of coupling:

• Temporal coupling — caller and callee must both be alive at the same instant.
• Behavioural coupling — the caller depends on the callee's response structure and error codes.
• Performance coupling — the caller's response time is bounded below by the callee's processing time.

EDA eliminates all three. The producer has no knowledge of its consumers; a new consumer can subscribe to existing events without any producer code change. The system can scale consumer instances independently, and a slow consumer does not delay the producer.

Trade-offs of EDA:

• Eventual consistency — consumers process events asynchronously; the system is not instantly consistent after an event is published.
• Harder debugging — end-to-end request flows are reconstructed by correlating events across distributed logs rather than reading a single call stack.
• Event schema evolution — changing an event's schema is a breaking change for all consumers; requires careful versioning (additive changes only, or explicit versioned event types).
• No immediate response — EDA is unsuitable for interactions that require a synchronous return value (e.g., a login that must return a JWT).

EDA and request/response often coexist in the same system: synchronous for user-facing read operations that need immediate results; asynchronous events for state change propagation across service boundaries.