Most DVA-C02 scenarios describe an application built from small pieces that talk to each other, and ask which design keeps it reliable and easy to change. The underlying idea is coupling: how much one component needs to know about, and wait for, another. A tightly coupled system breaks as a whole when one part is slow or down. A loosely coupled system puts something in between (a queue, a topic, an event bus or an API contract) so each part can fail, scale and be deployed on its own.
In an event-driven architecture, components announce that something happened (an order was placed, a file was uploaded) instead of calling each other directly. The producer emits an event and moves on; any number of consumers react to it. On AWS the usual carriers are Amazon Simple Queue Service (SQS) for work queues, Amazon Simple Notification Service (SNS) for publish/subscribe, Amazon EventBridge for routing events by content, and Amazon Kinesis Data Streams for ordered, high-volume streams. Many AWS services, such as Amazon S3 and Amazon DynamoDB, can emit events that trigger AWS Lambda functions directly.
Microservices apply the same thinking to the whole application: split it into small services, each owning one business capability and its own data store, deployed independently and reached only through its API or its events. The benefit is independent scaling and release; the cost is more network calls, more things to monitor and the need to handle partial failure. A common exam distractor is a design where two services share one database table, which quietly couples them again.
Fan-out means one message is delivered to many consumers in parallel. The classic AWS pattern is SNS to multiple SQS queues: a producer publishes once to a topic, and each subscribed queue gets its own copy, so an email service, an analytics service and an inventory service each process at their own pace, and a slow consumer never blocks the others. EventBridge rules with several targets achieve a similar result with content-based filtering.
Choreography and orchestration are two ways to coordinate a multi-step business process. In choreography, there is no central controller: each service listens for events and emits new ones, like dancers who each know their part. It is very loosely coupled but the overall flow is hard to see and debug. In orchestration, one coordinator, typically AWS Step Functions, calls each step, tracks state, and handles retries and compensation. Choose orchestration when you need visibility, ordering, error handling or human approval steps; choose choreography when services should evolve independently and simply react to events.
Stateless design is what lets all of this scale. A stateless compute unit keeps no session or user data in its own memory or local disk between requests, so any instance or Lambda execution environment can serve any request and can be replaced at any moment. State lives in an external store such as DynamoDB, Amazon ElastiCache or S3. Sticky sessions and data kept only in /tmp are signs of a stateful design that will not scale out cleanly.
Key terms
- Loose coupling
- Designing components so they interact through an intermediary or stable contract, letting each fail, scale and deploy independently.
- Fan-out
- Delivering one published message to many subscribers in parallel, for example an SNS topic with several SQS queue subscriptions.
- Choreography
- Coordination where each service reacts to events and emits new ones with no central controller.
- Orchestration
- Coordination where a central workflow engine, such as Step Functions, invokes each step and manages state and errors.
- Stateless service
- A service that keeps no client state between requests, storing it externally so any instance can handle any request.
An online shop's checkout Lambda function publishes an OrderPlaced message to an SNS topic. Three SQS queues subscribe: one feeds the payment service, one the warehouse service and one the email service. When the email provider has an outage, messages simply wait in its queue while payments and shipping continue normally.
Check yourself
Why is SNS publishing to several SQS queues more resilient than SNS invoking several services directly?
Each queue buffers messages for its consumer, so a slow or failed consumer can catch up later without losing messages or delaying other consumers.
When would you choose orchestration over choreography?
When the process needs a central view of state, strict ordering, retries or compensation for failed steps, or human approval, which a Step Functions state machine provides.
What makes a web tier stateless?
It stores session and user data in an external store such as DynamoDB or ElastiCache instead of instance memory or local disk, so any instance can serve any request.