Point-to-Point vs. Event Bus
Imagine a busy restaurant kitchen. In a poorly run kitchen, every waiter walks directly to each chef to place an order. If the pasta chef is busy, the waiter waits. If you add a new dessert chef, every waiter needs to learn to walk to a new station. This is tight coupling — every participant needs to know about every other participant, and failures cascade.
A well-run kitchen has an order board in the middle. Waiters pin tickets to the board and walk away. The pasta chef, grill chef, and dessert chef each watch the board for tickets relevant to them. No waiter waits. No chef is blocked by another chef's problems. Adding a new chef just means they start watching the board — no waiter changes required.
Amazon EventBridge is that order board for your AWS architecture. It is a fully managed, serverless event bus that decouples producers (services that generate events) from consumers (services that react to events).
In the old model, if Service A needed to notify Service B, it called Service B's API directly (HTTP/REST). This creates three problems:
- Availability coupling: If Service B is down, Service A's call fails.
- Scalability coupling: If 10,000 events arrive at once, Service B must handle all of them immediately.
- Knowledge coupling: If you want Service C to also receive the event, you must modify Service A's code to add a new API call.
With EventBridge, Service A (the Producer) simply emits an event: "An order was placed." EventBridge receives it. Services B, C, and D (the Consumers) have independently configured rules that say "I care about order events — route them to me." Service A has zero knowledge of who is listening. This pattern is called fire-and-forget, and it is the foundation of event-driven architecture.
Key Components
- Event Bus: The pipeline through which events flow. Think of it as the order board itself.
- Events: JSON payloads that describe something that happened. Events are facts — immutable records of past occurrences.
- Rules: Filter logic attached to a bus. A rule says "when an event matches this pattern, send it to this target."
- Targets: The AWS services that actually do something when a rule matches — Lambda functions, SQS queues, SNS topics, Step Functions state machines, and more.
Interviewers frequently ask: "What is the difference between EventBridge, SNS, and SQS?" The concise answer: SQS is a queue for point-to-point work distribution (one producer, one consumer group). SNS is a pub/sub system for fan-out notifications (one topic, many subscribers, but limited filtering). EventBridge is a content-aware event router with rich JSON pattern matching, schema registry, and native integration with 200+ AWS services and SaaS partners. Use EventBridge when you need sophisticated routing logic, cross-account event delivery, or SaaS integrations. Use SNS when you need simple fan-out with minimal filtering. Use SQS when you need durable buffering and work queues.
Key Point: EventBridge is not a replacement for SQS or SNS — it is a complement. A common production pattern is: EventBridge routes an event → to an SNS topic → which fans out to multiple SQS queues → each consumed by a different microservice. This gives you routing intelligence, fan-out, and durable buffering in a single pipeline.