Architectural patterns and decoupling: DVA-C03 study notes and practice questions
What to know about Architectural patterns and decoupling for the DVA-C03 exam, from the Development with AWS Services domain (30% of the exam guide), then 2 free questions to test it. Part of the DVA-C03 study guide.
Architecture questions describe a system and a requirement, such as “each team must work at its own speed” or “the producer must not change when a consumer is added,” and ask which design meets it with the least coupling.
Coupling
Tightly coupled: a caller knows the callee’s address, waits for its answer and fails when the callee fails. A chain of direct REST calls is tightly coupled.
Loosely coupled: the producer sends work or events to a service in the middle, such as a queue, topic or event bus, and does not know who consumes them.
Loose coupling lets each side scale, deploy and fail independently. A queue also absorbs bursts, so a slow consumer does not cause dropped requests.
How to choose
Scenario wording
Pattern
The caller needs the answer now, such as a price or a login
Synchronous request and response, for example API Gateway to Lambda
The work is long, or the caller does not need the result right away
Asynchronous: accept the request, queue the work, return 202 Accepted with a job ID, and let the client poll or get notified
One event must reach several independent consumers
Fanout: an SNS topic with one SQS queue per consumer, or an EventBridge event bus with one rule per consumer
Several steps that need order, waits, retries and an audit trail
Orchestration with Step Functions
Consumers must not lose events during an outage
A queue per consumer, not a direct call
Event-driven patterns
Choreography: services react to events on a shared bus, with no central controller. Adding a consumer means adding a rule or subscription, not changing the producer.
Orchestration: one state machine calls each step and tracks its state. Choose it when order, retries and visibility of each run matter.
Duplicates: asynchronous designs can deliver a message more than once, so consumers should be idempotent.
Common traps
Sequential synchronous calls to several consumers. The producer waits on each one, and one outage stops the whole request.
One shared queue for several teams. Consumers compete for messages, so each event reaches only one team. Put a topic in front and give each team its own queue.
Sticky sessions or local state when the question asks for scale-out. Store shared state in a service such as ElastiCache or DynamoDB so any instance can serve any request.
Direct HTTPS subscriptions for events that must not be lost. A queue behind the topic keeps the events until the consumer is ready.
Long jobs inside a synchronous API call. Accept the request, process the job asynchronously and let the client check its status.
A video platform publishes an event whenever a creator's upload finishes.
Three independent teams need every event: thumbnail generation, captioning and recommendations.
Each team must work at its own speed and must keep events that arrive while its service is down for a few hours. The upload service should not need a code change each time a new team starts consuming events.
Which design meets these requirements with the LEAST coupling between the services?
Choose one answer.
AA. Have the upload service call each team's REST endpoint in sequence, and retry any call that fails until it succeeds.
BB. Write each upload event to one Amazon SQS standard queue that all three teams poll.
CC. Publish each upload event to an Amazon SNS topic, and subscribe a separate Amazon SQS queue for each team.
DD. Publish each upload event to an Amazon SNS topic, and subscribe each team's HTTPS endpoint directly.
Show the answer and explanation
Answer: C
A. Wrong: This is synchronous, so the upload service must know every consumer and wait on each one. A team that is down for hours forces the upload service to hold and retry events, and every new consumer needs a code change upstream.
B. Wrong: Teams that poll the same queue compete for messages, so each event would reach only one team. Every team needs its own copy of every event.
C. Right: Correct. This is the fanout pattern: SNS copies each event to every subscribed queue, and each queue holds events until its team reads them. The upload service publishes once and does not know who is listening, so a new team needs only a new subscription.
D. Wrong: Every team is sent the event, but SNS stops retrying an HTTPS endpoint after a limited time and then discards the message. A team that is down for hours can lose events, which a queue per team would prevent.
Explanation
The SNS-to-SQS fanout pattern decouples the producer from its consumers. The upload service publishes once and does not know who is listening. SNS copies the event to every subscribed queue, and each queue holds its messages until its own team reads them, so the teams scale and fail independently.
One publish, one queue per team. A new team subscribes its own queue, and the upload service does not change.
A quiz app runs on Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer.
Each player's score and current question are kept in the memory of the instance that serves that player. When the group scales in, players lose their progress. The developer must let any instance serve any player while keeping scale-in working.
What should the developer change?
Choose one answer.
AA. Store each player's progress in Amazon ElastiCache, which all instances share.
BB. Turn on sticky sessions on the load balancer so each player stays on one instance.
CC. Increase the instance size so each instance has more memory for player progress.
DD. Write each player's progress to the instance store volume of the instance that serves them.
Show the answer and explanation
Answer: A
A. Right: Correct. Moving progress out of the instances makes the web tier stateless, so any instance can serve any player. Scale-in then removes an instance without removing anyone's progress.
B. Wrong: Sticky sessions keep a player on one instance, but when that instance is deregistered or unhealthy, the load balancer moves the session to another target and the progress on the old instance is lost. Scale-in still loses progress.
C. Wrong: Larger instances still keep progress locally. When scale-in terminates one of them, the progress held there is lost just the same.
D. Wrong: Instance store is local to one instance, and its data does not survive when that instance is terminated. It fails the same requirement as in-memory storage.
Explanation
A stateless design keeps no player state on the compute layer. A shared in-memory store such as ElastiCache lets any instance read any player's progress, so the Auto Scaling group can scale in freely. Sticky sessions, bigger instances and local storage all keep the state on the instance that is about to be removed.
Want more on Architectural patterns and decoupling? The 5 full-length practice sets have 5 more Architectural patterns and decoupling questions, 390 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →