Architecture Patterns
Also known as: EDA
An architectural style where services communicate primarily by emitting and reacting to events, rather than calling each other directly.
In an event-driven architecture, services express what happened (a domain event: "OrderPlaced", "PaymentSucceeded", "UserSignedUp") rather than what should happen next. Other services subscribe to events they care about and react independently. The result is loose coupling: a service that emits an event has no idea who consumes it, and consumers come and go without affecting the producer.
EDA shines when the workflow has many independent reactions to a single trigger. A new user sign-up might fan out to send a welcome email, create a Stripe customer, update analytics, post to Slack, refresh recommendations — each handled by a different service that subscribed to the event. Adding a new reaction is a deploy of one service, not a coordinated change across many.
The pattern requires investment in event infrastructure (Kafka, Pulsar, EventBridge, NATS), schema discipline (events are a public API and must evolve carefully), and observability (tracing a request across many event hops is harder than following a synchronous call chain).
Use EDA when many services need to react to the same domain change, when workflows are inherently asynchronous, and when teams need to evolve independently.
Event-driven systems are harder to debug, require careful event schema management, and shift complexity into observability. Eventual consistency becomes pervasive.
A messaging pattern where publishers emit messages to topics without knowing who consumes them, and subscribers receive messages from topics they care about.
A buffer that holds messages between producers and consumers, enabling asynchronous processing and decoupling of services.
A pattern that separates the model used for writing data (commands) from the model used for reading data (queries), allowing each to be optimized independently.
An architectural style that structures an application as a collection of small, independently deployable services, each responsible for a specific business capability.
A single deployable application containing all features and logic, sharing one codebase, one database, and one deployment unit.
A single entry point that routes external requests to internal services, handling concerns like authentication, rate limiting, and request transformation in one place.