- Learn AWS
- Architecture
- Fan-out to independent consumers
Architecture pattern
AWS Fan-out to independent consumers architecture
when one event, several teams, none of them blocking each other
A topic fans the message out; each consumer gets its own queue. One slow or broken consumer backs up only its own queue, and its failures retry there instead of taking the publisher down with them.
What it runs through
In the order a request or a record moves through it. Each one links to the page that explains it.
Signals in a brief that point here
Phrases that, when you meet them in a scenario, mean this shape rather than another. They are the tell, and they are what an exam question is built around.
- “notify several systems”
- “each team owns their handler”
- “one consumer must not affect another”
What it costs you
Every consumer needs its own dead-letter handling, and ordering across queues is not guaranteed.
Every shape has one. A design decision with no stated downside is usually a decision nobody has finished making.
Learn the services in it
- AWS SNSPublish once to a topic, and SNS pushes a copy to every subscriber: SQS queues, Lambda functions, HTTPS endpoints, email, SMS and mobile apps.
- AWS SQSA queue between the part of your system that creates work and the part that does it, so a slow or broken consumer never costs you the work.
- AWS LambdaRuns your code in response to events, with no servers to manage. You pay per request and by the millisecond, and a run lasts 15 minutes at most.
Shapes it is easily confused with
These run through some of the same services, which is exactly why a brief that fits one can look like it fits another.
Now build it from a brief
Reading a shape and producing one from a scenario that never names a service are different skills, and the exam asks for the second. The scenarios give you the brief; you draw the architecture and it is scored against what the brief requires.