When there’s an event in the cloud, how many different receivers can receive it? There are two plausible answers: Just one, or anyone.
[This is part of the Event Facets series.]
Point-to-point · The idea is that any given message can only be read by one receiver. You might imagine that, as the old photo above suggests, the sender supplies an address, choosing the receiver. But that’s actually a pretty rare scenario. What’s much more common is the way that SQS works.
In SQS, when you send a message, you have to pick which queue you’re sending it on. Any number of receivers can be polling the queue, but only one will receive any given message. The API is clever; once you’ve received a message and processed it successfully, you’re supposed to delete it. There’s a time window after you’ve received it during which nobody else can see it. If the message isn’t deleted in time, it’ll pop back into availability. It’s called the “visibility timeout” and there are APIs for setting and adjusting it.
Think about a back-end system in one of Amazon.com’s warehouses, picking up order events from the Web site. You want enough event readers in the warehouse to keep it busy, and you want to have each order processed by only one of them; so this flavor of point-to-point is just the ticket.
It’s not a rare scenario at all; the Apache Artemis message broker calls it “anycast”.
Credit: Terje Skjerdal from Høvåg, Norway / CC BY
Pub/Sub · It’s short for “Publish and Subscribe”, which nobody ever says. This is probably the default mode for most of the software that has the word “event” in its name. The idea is, you publish your events onto a Bus or a Stream or a Topic or a Queue — there’s no standard terminology. Then receivers subscribe to the whatever-it’s-called and the events on it are in principle available to all of them.
There are all sorts of variations in how subscriptions work; push vs pull, filter vs firehose; they’re important enough to deserve their own entries in this series.
There are loads and loads of apps in every sector of business that are a good fit for pub/sub. I’d be amazed if there are readers in a business of any size that doesn’t have some running.
At AWS, we have multiple services that do pub/sub: Kinesis, Managed Kafka, MQ, and then my favorite, SNS, which is used by more or less everyone to do more or less anything. The way it works is, you publish messages to at Topic, and then you subscribe receivers to it. They can be SQS queues, Lambda functions, mobile-device messaging, and arbitrary HTTP endpoints. And you can have as many subscribers as you want, SNS will do the fan-out.
