After I got the core AWS services straight in my head, a new confusion showed up. I understood the pieces. I didn’t understand how they talk to each other. A Lambda function is nice, but how does anything reach it? How does one service hand work to the next without everything falling over when one part is slow?
That’s its own little family of services, and these are the ones that finally made sense to me. Here are the four patterns side by side:
API Gateway — the front door
API Gateway is the entrance for requests coming from the outside world. A browser or app sends an HTTP request, and API Gateway receives it, checks it’s allowed, and routes it to whatever should handle it, usually a Lambda function. It also deals with the unglamorous gatekeeping: authentication, rate limiting, and the CORS rules I once spent a whole afternoon fighting in theory.
Plain version: it’s the front desk. Requests come in here, get checked, and get sent to the right place.
SQS vs SNS — “a line” vs “a megaphone”
These two sound similar and do opposite things.
SQS is a queue. One part of the system drops messages in, another part picks them up when it’s ready. Work waits patiently in line until someone processes it. It’s how you stop a slow step from crashing a fast one: the line absorbs the pressure.
SNS is a broadcast. One message goes out, and every subscriber gets a copy, all at once. Email, a Lambda, a queue, whatever’s listening.
The way it stuck: SQS is a line at a counter, served one at a time when staff are free. SNS is a megaphone announcement everyone hears immediately.
EventBridge — the smart router
EventBridge is also about broadcasting, but with brains. Services emit “events” (something happened), and EventBridge routes them to the right targets based on rules you write. “When this kind of thing happens, send it there.”
If SNS is shouting to everyone, EventBridge is a switchboard that listens for specific things and forwards them to exactly who cares. It’s the backbone of the “event-driven” architectures I kept hearing about and couldn’t picture.
Why this matters more than it looks
Understanding the glue changed how I read solutions. The interesting design decisions usually aren’t in the individual services, they’re in how the work flows between them: what waits in a queue, what fans out, what triggers what. In discovery now, I can follow that flow instead of just nodding at it.
Quick reference, for future me
| Service | What it does | Plain version |
|---|---|---|
| API Gateway | Receives and routes external requests | The front desk |
| SQS | Holds messages until a consumer pulls them | A line at a counter |
| SNS | Broadcasts a message to all subscribers | A megaphone |
| EventBridge | Routes events to targets by rules | A smart switchboard |
Same honest caveat as always: I understand how these connect, I haven’t wired them together myself yet. But the picture in my head keeps getting more specific, and that’s exactly the direction I want it moving.