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.
| 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. |