You walk into a busy Ghana bank. There's a queue. There's an announcer calling numbers. There's a receptionist who decides where each customer goes. Three completely different ways of moving people around — and each is exactly how AWS moves messages between your services.
Take a numberImagine the inside of GCB's main branch in Accra. Customers come in needing different things — deposits, withdrawals, statements, account opening, loan inquiries. The bank can't just let everyone rush the tellers at once.
So the bank uses three different systems to handle the flow:
1. A numbered queue — pull a ticket, wait your turn, one teller serves you.
2. A public announcer — "All loan officers, please come to the front desk!" — broadcasts to many people at once.
3. A smart receptionist — asks what you need, then sends you to the RIGHT department based on the answer.
In AWS, you have all three. They look intimidating with names like SQS, SNS, and EventBridge — but they're just digital versions of what GCB already does every day.
You walk in, pull a numbered ticket — say, #42. The screen says "now serving #38." So you sit down. You wait. Eventually the screen shows #42, and a teller calls you to window 3.
Notice three important things:
• You don't pick a teller. Whoever's free serves you.
• Only ONE teller serves you. Not three. Not all of them. Just one.
• If all tellers are busy, you wait. The line just gets longer. Nobody panics. Nobody loses their place.
This is the entire idea of SQSSQS = Simple Queue Service. Messages sit in a queue and are pulled by ONE consumer. If consumers are slow or down, messages just wait. Perfect for processing tasks one at a time. — Simple Queue Service. One sender drops a message in the queue, one worker picks it up, processes it, deletes it. If the worker crashes? The message goes back to the queue and another worker picks it up. Nothing gets lost.
Use SQS when: you have tasks that need to be done one at a time, in order or otherwise — like processing orders, sending emails, generating PDFs, running batch jobs.
Now the bank manager grabs a megaphone and shouts: "ATTENTION! All loan officers, all account managers, all customer service reps — please report to the main floor immediately!"
One announcement. Many people hear it. EVERYONE who's listening responds. The loan officers come. The account managers come. The CS reps come. They all act on the same single announcement, in parallel, at the same time.
Notice the difference from the queue:
• Many recipients hear the same message at once
• Nobody waits in line — it's broadcast
• The announcer doesn't care who responds or how long they take
This is SNSSNS = Simple Notification Service. A pub/sub system. ONE message gets fanned out to MANY subscribers — could be email, SMS, Lambda functions, SQS queues, all at once. — Simple Notification Service. One publisher sends a message to a "topic." Anyone subscribed to that topic gets a copy. Could be 1 subscriber. Could be 1,000.
Real example: an order is placed. SNS broadcasts that fact. The shipping system gets notified. The email system gets notified. The fraud detector gets notified. Everyone reacts simultaneously.
Use SNS when: something happens and multiple systems need to know about it — order placed, file uploaded, alarm triggered, payment received.
Now meet the bank's receptionist. She sits at a desk near the entrance with a clipboard. Every customer that walks in goes to her FIRST. She asks: "Good morning, how can I help you today?"
The customer says "I want to open a savings account" — she sends them to account opening.
Another says "I lost my ATM card" — she sends them to card services.
A third says "I want a loan over 100,000 cedis" — she sends them to the senior loan manager, NOT the regular loan desk.
She doesn't broadcast. She doesn't queue. She reads the request and routes it intelligently based on rules.
This is EventBridgeEventBridge is an event bus that lets you route events to different targets based on rules. You can filter by content, transform data, and even integrate with SaaS apps like Stripe, Datadog, Zendesk.. It's the most flexible of the three. Events come in. Rules look at the content. Each rule sends matching events to specific targets — Lambda, SQS, SNS, even external SaaS apps.
It's like SNS with a brain. Or SQS with rules.
Use EventBridge when: different events need different reactions — "if order > $1000 alert finance, if order < $50 just send confirmation, if from VIP customer notify account manager."
Newbies always get this question wrong on the cert. The trick is asking ONE question:
"How many things should react to this message?"
• One thing reacts → SQS (queue, one worker)
• Many things react, all the same way → SNS (broadcast)
• Different things react based on content → EventBridge (smart routing)
A few real-world examples:
Order placed → many systems care (shipping, billing, email, fraud) → SNS
Image upload to be resized → one Lambda needs to pick it up and process it → SQS
Customer activity stream → if VIP, alert manager; if international, run compliance check; otherwise just log → EventBridge
A pro tip: SNS + SQS together is one of the most common AWS patterns. SNS broadcasts, and each subscriber is its own SQS queue, so each system processes at its own pace.
When you see a question about queues, topics, or event buses on the cert — picture GCB. The numbered line. The megaphone. The receptionist with the clipboard. The right answer becomes obvious.
One sender, one worker. Tasks line up. If the worker fails, the message comes back.
One message broadcasts to many subscribers. Everyone reacts in parallel.
Reads the request. Applies rules. Routes to the right target based on content.
"AWS messaging isn't magic. It's just a well-organized banking hall."
Read the story again