Messaging, integration and business applications

A queue holds work until somebody does it

Amazon SQS is a pull-based queue: producers write messages, a consumer polls for them, and a message stays until it has been processed and deleted. A visibility timeout stops two workers picking up the same message, and a dead-letter queue collects whatever repeatedly fails so it can be looked at rather than lost. The value is loose coupling — either side can be slow, restarting or scaling while the other carries on.

That is why a checkout calling a fulfilment service directly and waiting for an answer is the shape a queue fixes. With the queue in the middle, a spike or an outage in fulfilment becomes a growing backlog instead of failed checkouts and lost orders. The two options offered against it are both real improvements to something else: retries with a longer timeout leave checkout coupled to fulfilment's health and make the customer wait longer before being told it failed, and a larger instance simply raises a ceiling that the next spike goes over in the same way.

A topic tells everybody, once

Amazon SNS is publish-and-subscribe: one message is delivered to every subscriber, and a subscriber can be an email address, an AWS Lambda function, an SQS queue or an HTTPS endpoint. That is the fan-out pattern, and its virtue is that the publisher knows nothing about the destinations — adding a fifth one next month is a subscription rather than a change to the code that publishes.

The misreading the exam tests is using a queue for this. A message on a queue is processed by ONE consumer and then deleted, so four pollers on one queue would each get a share of the messages rather than all of them getting every message. Publishing to a topic whose subscribers are queues is the classic combination, because each consumer then gets its own buffer. Amazon EventBridge does a related job with content-based routing rules and a much wider set of AWS and third-party targets.

When the sequence itself is the problem

When functions invoke each other directly, the orchestration is scattered through the code and nowhere is the state of one application written down — which is precisely the complaint in a stem that says nobody can tell where a stalled request stalled. AWS Step Functions moves the sequence out into a state machine: the order, the retries, the branch when a check comes back negative and the wait for a human approval are all declared outside the functions, and every execution leaves a visible history.

The distractors here are the other integration services doing what they are good at, in the wrong place. More Lambda functions is more of the same scattering. A queue between each pair of steps decouples them beautifully and expresses no sequence and no branching, so one application's state ends up spread across six queues with nothing joining it up. A scheduler starts things at a time, and timing is not the problem.

Applications you buy rather than build

This part of the syllabus also names business applications that are bought whole rather than assembled: Amazon Connect is a cloud contact centre, and Amazon SES sends bulk and transactional email. Their exam value is simply recognising what each one is for, so that an option naming SES in a question about four different destinations can be rejected as solving one quarter of the problem.

The pattern across the whole objective is the same one: each service answers a specific question, and a wrong answer is nearly always a service that answers a neighbouring question well. Sort them by the question and the options stop looking alike — what happens next is Step Functions, who does the work is SQS, who needs to know is SNS, and which of many targets should receive this event is EventBridge.