If you're new to cloud development, "event-driven architecture" might sound like technical jargon. But it's actually a concept you already use in everyday life. When you order coffee at a cafe, the barista starts making it and you're free to do other things while you wait. That's exactly what event-driven architecture is: when an "event" (like an order) happens, related services each react on their own.
Monolithic vs Microservices
Let's start with why this kind of structure is needed in the first place.
In the past, a common approach was to put all features into one giant program (monolithic). For an online store, that means login, product search, payment, and delivery tracking all live inside a single codebase. The problem is that fixing even one small part — say, the payment feature — requires redeploying the entire system. It's like having to vacate an entire building just to fix one room.
Microservices solve this problem. Login, payment, and delivery are each split into independent, small services. If the payment service has a problem, login and product search keep working fine. Think of it like an apartment complex where each building operates independently.
Coupling — How Services Connect to Each Other
Once you've split your system into multiple services, how they connect to each other matters enormously.
Tight Coupling is like Service A calling Service B directly by phone. If B doesn't pick up (goes down), A can't do anything at all.
Loose Coupling is like A leaving a note in a mailbox for B to pick up and handle later. Even if B is temporarily away (goes down), A can keep leaving notes, and when B comes back, it processes them in order. In AWS, SQS (Simple Queue Service) plays the role of that mailbox.
Synchronous vs Asynchronous Processing
Synchronous means you order coffee and stand at the counter waiting until it's ready. Calling Lambda directly through API Gateway and waiting for a response is a classic example.
Asynchronous is like ordering via a coffee app, sitting down to work on something else, and going to the counter only when your buzzer goes off. When Lambda is triggered via SNS or SQS, the caller returns immediately and results are checked later.
Asynchronous patterns offer three key advantages. First, they handle large volumes of simultaneous requests (scalability). Second, a failure in one part doesn't stop the whole system (fault tolerance). Third, each service works independently without interfering with others (independence).
Key Patterns
Fan-out
Think of it as broadcasting. One event is delivered to multiple services at the same time. For example, when a new order comes in, the inventory service, payment service, and notification service all receive the news simultaneously and act on it.
In AWS, an SNS topic acts as the broadcast station, and each SQS queue acts as a subscriber. The pattern of connecting one SNS topic to multiple SQS queues — the SNS + SQS fan-out — is the most frequently tested pattern on DVA-C02.
Orchestration vs Choreography
Orchestration works like a conductor leading an orchestra — a central authority says "start service 1, then when it's done, start service 2" and controls the entire flow. AWS Step Functions plays this role. It lets you manage complex workflows visually and track the success or failure of each step.
Choreography is like a flash mob. When the music starts (an event fires), each participant performs their assigned move. There is no central conductor; each service sees the event and responds on its own. AWS EventBridge serves as this event bus.
!Orchestration versus Choreography
Step Functions in Detail
Step Functions is a workflow service that connects multiple Lambda functions or AWS services in sequence. There are two types depending on how they execute.
The Standard type can run for up to one year and keeps a full audit log of every execution. It's suited for important business processes.
The Express type runs for up to five minutes, is extremely fast, and costs less. It's used when processing hundreds of thousands of short events per second.
State types include Task (runs work), Choice (conditional branching), Parallel (parallel processing), Wait (introduces a delay), Map (processes arrays), and Succeed and Fail.
Exam Key Points
"One event to multiple services simultaneously" -- SNS fan-out
"Central workflow management" -- Step Functions (orchestration)
"Services independently react to events" -- Choreography (EventBridge)
"Service B failure doesn't affect A" -- Loose coupling (use SQS)
"Components that don't store state" -- Stateless design
"Request and return immediately, check results later" -- Async pattern
"Short execution, high throughput workflow" -- Step Functions Express
SNS + SQS fan-out = most frequently tested DVA-C02 pattern