Development with AWS Services
Data Access Patterns, DynamoDB, Caching, and Specialized Stores
CoreChoose and implement data-store keys, consistency, operations, serialization, lifecycle, caching, and search from the application access pattern.
Aligned to AWS Certified Developer - Associate (DVA-C02) Version 2.1, verified August 23, 2026.
Why this matters
A developer must translate reads, writes, freshness, relationships, search, hot paths, and retention into the correct data operation. Treating every managed store as a generic database causes both correctness and performance failures.
Must Know
- Choose a high-cardinality DynamoDB partition key that distributes traffic while supporting required access patterns; low-cardinality or constantly hot values can concentrate load.
- A composite primary key groups items by partition key and orders them by sort key. A secondary index supports an additional query pattern; it does not replace a sound base key.
- Query uses a partition-key value and optional sort-key condition. Scan reads items across a table or index; a filter does not turn a Scan into a key-targeted Query.
- DynamoDB tables and local secondary indexes support eventual or strong reads. Global secondary indexes and streams are eventually consistent.
- Conditional or version-aware writes prevent blind lost updates when multiple callers change one logical item.
- Serialization must preserve the data types and schema contract needed to reconstruct the application object; handle schema evolution deliberately.
- DynamoDB time to live marks expired items for automatic deletion; expiration is not an exact-time scheduler or a synchronous business event.
- A cache accelerates repeated reads but needs correct keys, tenant boundaries, a source of truth, TTL or invalidation, and a stated freshness tolerance.
- Use relational stores for relational transactions and joins, key-value stores for known-key access at scale, caches for reusable temporary results, and OpenSearch Service for indexed search and relevance patterns.
Compare and Distinguish
- Partition key vs secondary index: the base key determines item identity/distribution; an index adds another access path with its own key.
- Query vs Scan: Query targets an item collection by key; Scan examines a broader set before filtering.
- Strong vs eventual consistency: strong reads prioritize latest committed data where supported; eventual reads trade immediate freshness for a different read model.
- DynamoDB vs Aurora/RDS: DynamoDB fits key-oriented access without relational joins; Aurora/RDS fit relational schemas, SQL, and transaction patterns.
- ElastiCache vs source data store: the cache reduces repeated work but is not automatically the durable source of truth.
- OpenSearch Service vs DynamoDB: OpenSearch supports indexed text/search analytics; DynamoDB supports predictable primary-key access.
Scenario examples
- Scenario: Read all events for one device in timestamp order. Use the device as partition key and time-oriented value as sort key.
- Scenario: A just-written table item must be confirmed immediately. Request a strongly consistent read from the table where supported, not from a GSI.
- Scenario: Product lookup uses an exact ID and also a full-text description search. Keep appropriate source persistence and use OpenSearch Service for the indexed search path.
- Scenario: A repeated catalog read tolerates sixty seconds of staleness. Use a tenant-aware cache key and TTL/invalidation aligned with that bound.
Exam traps
- A Scan filter reduces returned items but not the items read before filtering.
- Global secondary indexes do not support strongly consistent reads.
- High cardinality helps distribution only when the key also supports the required retrieval pattern.
- DynamoDB TTL deletion is asynchronous; do not use it as an exact deadline trigger.
- Caching authorization results or tenant data under an incomplete key can create a security defect.
- OpenSearch Service should not automatically become the authoritative transactional store.
Key takeaways
- Begin with access patterns, freshness, and transaction requirements.
- Make primary keys distribute traffic and make common reads key-targeted.
- Use conditional writes for concurrent update safety.
- Treat lifecycle, cache freshness, and search indexing as separate roles.
- Preserve tenant and type boundaries through serialization, keys, indexes, and caches.
How it works
- The application serializes an object into a stable store representation.
- Primary and secondary keys route supported queries to the required item collection or alternate access path.
- Consistency and conditional settings define read freshness and write conflict behavior.
- Lifecycle removes expired source records, caches serve safe repeated reads, and search indexes serve specialized retrieval.
When to use it
- Use DynamoDB for access patterns built around known keys and scalable item operations.
- Use Aurora or Amazon RDS when relational semantics and SQL are decisive.
- Use ElastiCache when repeated work can be reused within an explicit correctness window.
- Use OpenSearch Service when full-text, relevance, or search analytics are required.
- Use Amazon S3 for durable object storage and lifecycle-managed objects rather than keyed record queries.
Security and governance implications
- Authorize only the required table, index, item, cache, search, or object actions.
- Include trusted tenant context in keys and authorization, not just a presentation-layer filter.
- Encrypt data and connections as required and keep credentials in workload roles or managed secrets.
- Do not serialize secrets or sensitive fields into caches and indexes without the same protection boundary as the source.
Failure signals and diagnosis
- For throttling or uneven latency, inspect partition-key distribution and the exact access operation before raising capacity.
- For stale reads, identify whether the read came from a table, LSI, GSI, stream, or cache and which consistency mode applies.
- For missing query results, inspect key conditions, index projection, serialization, and tenant key construction before scanning.
- For stale cache results, inspect key scope, TTL, invalidation timing, and source update behavior.
More detail
- A developer defines keys and indexes from application access patterns; the lane does not require enterprise database-schema design.
- Read consistency and write concurrency are separate: a strong read does not make a later write atomic.
- Data lifecycle controls storage retention; application workflows that must run at a precise time need a separate reliable trigger.
- Cache correctness includes invalidation, key scope, failure behavior, and protection against cross-tenant reuse.
Ready for the quiz?
- Why can a filtered Scan still be expensive?
- Which DynamoDB surfaces support strongly consistent reads?
- When is a secondary index required?
- What must a cache design state besides the cache service name?
- Why is OpenSearch Service not simply a faster DynamoDB Query?
Related objectives
- D1.3 — Use data stores in application development
- 1.3.1 — Describe high-cardinality partition keys for balanced partition access
- 1.3.2 — Describe database consistency models (for example, strongly consistent, eventually consistent)
- 1.3.3 — Describe differences between query and scan operations
- 1.3.4 — Define Amazon DynamoDB keys and indexing
- 1.3.5 — Serialize and deserialize data to provide persistence to a data store
- 1.3.6 — Use, manage, and maintain data stores
- 1.3.7 — Manage data lifecycles
- 1.3.8 — Use data caching services
- 1.3.9 — Use specialized data stores based on access patterns (for example, Amazon OpenSearch Service)