The Service, Decided — No. 1

Every architecture has a moment, usually in week two, when one system first needs to tell another system something. Nobody schedules a meeting about it. A developer picks a service, wires it up, and moves on — and that quiet choice is still shaping the system five years later, long after the person who made it has left.

On AWS, the choice usually comes down to three services that look interchangeable from a distance and are not interchangeable at all: Amazon SQS, Amazon SNS, and Amazon EventBridge. A queue, a topic, and a bus. The feature lists overlap enough to make the decision feel cosmetic. It isn't. Each one encodes a different answer to the same question: when something happens, who owns what happens next?

Three shapes of "something happened" — ask what the message is, and the service follows.

The queue: work that waits

SQS is a holding pen for work. A producer drops a message in; a consumer takes it out when it is ready. The message waits — four days by default, up to fourteen — and that waiting is the point. The producer and the consumer run at their own speeds, and neither has to care about the other.

That makes SQS the right shape whenever the message is a task: process this payment, resize this image, sync this record. The decision it forces is about guarantees, and it comes in two flavors. A standard queue offers effectively unlimited throughput, delivers messages in roughly the order they arrived, and makes no promise against delivering the same message twice. A FIFO queue promises strict order and exactly-once processing — and, in its default (non-high-throughput) mode, caps you at 300 transactions per second per partition (3,000 messages per second with batching) for the privilege. High-throughput mode can raise that ceiling sharply, but it does so by partitioning the work — the ceiling does not disappear, it moves.

The trap is treating that as a settings page. Ordering and duplication are not preferences; they are properties your consumers will be designed around. Pick standard, and every consumer you ever write must be idempotent. Pick FIFO, and you have bought correctness with a throughput ceiling you will meet on your worst day, not your average one. SQS also gives you the honest failure machinery — dead-letter queues for messages that keep failing, visibility timeouts that decide how long a message stays hidden while someone works on it. A queue is a promise that work will not be lost. What it asks in return is that you decide, up front, what "done" means.

The topic: news that spreads

SNS answers a different question. A topic is a broadcast: one message, published once, delivered immediately to every subscriber — other services, Lambda functions, HTTP endpoints, email, SMS, mobile push. Nothing waits. SNS pushes; it does not hold.

That makes SNS the right shape when the message is news: the order was placed, the file arrived, the alarm fired — and several independent parties each want to react in their own way. The publisher doesn't know or care who is listening. Adding a new listener changes nothing upstream.

The trap is symmetry with SQS. Teams reach for SNS when they want fan-out and then discover they also wanted durability — a subscriber that was down, slow, or mid-deploy when the news broke. Push delivery has no memory. Which is why the most common honest answer in this whole comparison is not one service but a composition: SNS in front, SQS behind it — the topic spreads the news, a queue per subscriber holds each one's copy until it is ready to do the work. If your architecture review doesn't surface that pattern early, your incident reviews will surface it later.

The bus: events that route

EventBridge is the youngest of the three and the most ambitious. It is a serverless event bus: events arrive from AWS services, from SaaS applications, and from your own systems; rules match on the content of each event and route it to one or more targets, in parallel. It keeps a schema registry, so the shape of your events is a documented, versioned contract rather than folklore. You pay per event published to a classic bus — about a dollar per million custom events — and nothing for delivery to targets in the same account.

That makes EventBridge the right shape when the message is an event in a domain: not a task for someone, not an announcement to everyone, but a fact — order.shipped, payment.failed — that different parts of the business will want to route on, filter on, and react to in ways you haven't thought of yet. The decision it forces is governance. A bus rewards teams that treat event schemas as contracts and punishes teams that treat it as a junk drawer: once dozens of producers publish whatever shape they like, the routing layer becomes the place where nobody knows what depends on what.

The trap is reaching for the bus because it feels modern. If one producer hands work to one consumer, a bus is ceremony. If three teams need to react to the same domain events under rules that change quarterly, a point-to-point queue topology will quietly become the thing nobody dares to touch.

The decision, stated plainly

Ask what the message is:

Notice what is not on that list: throughput tables, pricing calculators, feature matrices. All three services are cheap at the scales most teams actually run, and all three scale past what most systems need. The costs that compound are not in the AWS bill. They are in the consumer written against a duplication guarantee nobody chose, the subscriber that missed news it needed, the bus full of undocumented event shapes. Integration decisions are load-bearing precisely because they are made casually, by whoever wires up the first connection, in week two.

The architect's job is not to pick the best service. It is to make sure the choice gets made on purpose — in the week when it is still cheap.