DVA-C02 data store questions focus on two main areas: choosing the right data store for a given situation, and knowing how to improve application performance with caching.
Choosing a Data Store — Picking the Right Database for the Job
Just as you would choose a refrigerator, a warehouse, or a safe depending on what you need to store, you should choose your data store based on the nature of your data and how it will be used.
| Requirement | Recommended Service | |-------------|-------------------| | Relational data, SQL queries | RDS / Aurora | | Key-value structure, millisecond response | DynamoDB | | In-memory cache (fast temporary storage) | ElastiCache | | Full-text search, log analysis | Amazon OpenSearch | | Files, images, large object storage | S3 |
What Is Caching?
Caching is the technique of storing frequently accessed data in a fast storage layer (memory) so it can be retrieved quickly. Think of it like keeping your favorite food in the refrigerator. It is much faster to grab something from the fridge (cache) than to go to the grocery store (database) every time you need it.
By using caching effectively, you can reduce database load and deliver much faster response times to your users.
Three Caching Strategies
Lazy Loading (Cache-Aside)
This is the most widely used caching strategy. Here is how it works:
A user requests data. The application first checks the cache. If the data is in the cache (Cache Hit), it is returned immediately. If the data is not in the cache (Cache Miss), the database is queried. The retrieved data is stored in the cache and returned to the user.
Advantage: only requested data is cached, so memory is used efficiently.
Disadvantage: a Cache Miss means the first request is slow. Also, stale data can remain in the cache for too long.
Solution: set a TTL (Time To Live). TTL defines how long cached data stays valid. When the TTL expires, the cache entry is automatically deleted, so the next request fetches fresh data.
Write-Through
Whenever data is written to the database, it is also written to the cache at the same time.
Advantage: cached data is always up to date. Cache Misses are very rare.
Disadvantage: data that is never read still gets stored in the cache, potentially wasting memory.
Write-Back (Write-Behind)
Data is written to the cache first, and then periodically flushed to the database in batches.
Advantage: write operations are extremely fast. Great for systems with heavy write loads.
Disadvantage: if the cache fails unexpectedly, data that has not yet been saved to the database can be lost.
!3 caching strategies: Lazy Loading, Write-Through, Write-Back
ElastiCache — AWS's In-Memory Cache Service
Amazon ElastiCache provides two engines: Redis and Memcached. Both store data in memory for extremely fast access, but they differ significantly in features.
| Feature | ElastiCache for Redis | ElastiCache for Memcached | |---------|----------------------|--------------------------| | Supported data types | Rich (String, Hash, List, Set, and more) | String only | | Replication (read replicas) | Supported | Not supported | | Data persistence (survives restart) | Supported | Not supported | | Multi-AZ automatic failover | Supported | Not supported | | Multi-threaded processing | Not supported | Supported |
In most cases, choose ElastiCache for Redis. Thanks to replication, persistence, and Multi-AZ support, it is more reliable and versatile.
Choose ElastiCache for Memcached only when you need simple caching and multi-threaded processing performance is a priority.
Data Serialization — The Format for Exchanging Data
When exchanging data with ElastiCache or other services, you need to convert data into a specific format (serialization) and then restore it back to its original form (deserialization). Think of it like putting a letter in an envelope and then taking it out.
Commonly used formats include JSON (human-readable), Protobuf (fast and efficient), and Avro (suited for large-scale data). The format you choose affects both performance and compatibility with other systems.
Exam Key Points
"Check cache on request -> miss -> query DB -> store in cache" -- Lazy Loading (Cache-Aside)
"Update cache simultaneously when writing to DB" -- Write-Through
"Automatically expire stale cache" -- Set TTL
"Need replication, persistence, Multi-AZ" -- ElastiCache for Redis
"Simple caching, multi-threaded processing needed" -- ElastiCache for Memcached
"Full-text search, log analysis" -- Amazon OpenSearch
"Keep cache data always up to date" -- Write-Through
Redis vs Memcached: choose Redis in most cases. Memcached is for special situations requiring simple caching plus multi-threaded performance.