Study DVA-C02 Concurrency, Caching, and Performance: key concepts, common traps, and exam decision cues.
Optimization questions on DVA-C02 are usually about reducing wasted work or sizing resources more intelligently. AWS wants you to know when the best first move is tuning concurrency, adding a cache, filtering messages before they fan out uselessly, or profiling where the bottleneck actually is.
Concurrency: Number of requests, invocations, or tasks that can run at the same time.
Subscription filter policy: Rule that lets a consumer receive only the messages that match specific attributes, reducing unnecessary downstream processing.
AWS wants you to classify:
| If the issue is mainly about… | Strong lane |
|---|---|
| repeated reads of the same hot data | caching |
| too many concurrent executions overwhelming a dependency | concurrency control |
| many subscribers processing messages they do not need | filter policies |
| unclear performance bottleneck | profiling plus logs and metrics |
| memory and compute fit for serverless or container execution | profiling plus sizing review |
| Need | Strongest first control | Why |
|---|---|---|
| protect a downstream dependency from bursty invocations | concurrency limits or reserved concurrency | The first requirement is controlled execution pressure. |
| reduce repeated expensive reads | application or service-level caching | Avoiding work is often stronger than doing the same work faster. |
| stop irrelevant subscribers from processing messages | subscription filter policies | Filter earlier so downstream code does less useless work. |
| diagnose whether memory or compute is undersized | profiling and runtime metrics | Guessing usually creates waste. |
| improve application response path | analyze where latency is introduced, then tune the right layer | Optimization starts with the bottleneck, not with a favorite service. |
flowchart TD
A["Performance problem"] --> B{"What kind of waste exists?"}
B -->|"Too many parallel executions"| C["Tune concurrency to protect downstream systems"]
B -->|"Same data read repeatedly"| D["Add caching at the right layer"]
B -->|"Unneeded subscriber work"| E["Use message filter policies"]
B -->|"Unknown bottleneck"| F["Profile, inspect metrics, and tune the constrained resource"]
Strong answers usually prefer removing wasted work before simply adding more capacity.
The exam likes to bait you into “just make it bigger.” Stronger answers usually prove the bottleneck first:
If you do not know which of those is true, profiling and metrics are usually stronger than resizing guesses.
Two very common cheap wins:
These are often better first answers than scaling because they eliminate unnecessary work instead of paying to process it faster.
| Trap | Better thinking |
|---|---|
| more concurrency is always better because it maximizes throughput | unlimited concurrency can crush downstream dependencies and increase failure rate |
| caching is always a database-only topic | application-level or edge caching can also remove repeated expensive work |
| every subscriber should just receive every event and decide later | filter policies reduce cost and wasted processing earlier in the path |
| tuning means bigger memory until the problem disappears | profile first so you know whether the limit is memory, CPU, concurrency, I/O, or design |
DVA-C02 usually rewards evidence-based tuning that matches the exact waste pattern instead of generic “more throughput” thinking.