Databases - ElastiCache
- ElastiCache is managed Redis or Memcached
- Key-value store
- Caches are in-memory databases with really high performance, sub-millisecond latency
- Leads to faster reads & stateless applications
- Must provision an EC2 instance type e.g.
cache.t2.micro & number of read replicas.
- Write Scaling using sharding
- Multi AZ with Failover Capability
- An alternative is DynamoDb with DAX.
- Monitoring through CloudWatch
- Backup / snapshot / point in time restore features
- Caching patterns
- Application queries ElastiCache, if not available, get from RDS and store in ElastiCache
- Cache hit: Get data directly from ElastiCache
- Cache miss: Data is not in the DB, application reads from DB and writes to the cache
- Cache must have an invalidation strategy to make sure only the most current data is used in there.
- Cache invalidation: whether or not the cache is out of date.
- Patterns for ElastiCache
- Lazy Loading: all the read data is cached, data can become stale in cache
- Write Through: Adds or update data in the cache when written to a DB (no stale data)
- Session Store: store temporary session data in a cache (using TTL features)
- ❗ None of the caches support IAM authentication
- IAM policies are only used for AWS API-level security, such as create a cache, delete a cache etc.
- Managed and Scheduled maintenance with SNS notifications
- Subnet group allows you to specify set of subnets in your VPC for your instances.
- 💡 Use case: Key/Value store, Frequent reads, less writes, cache results for DB queries (writethrough pattern), store session data for websites, cannot use SQL.
- In-memory object store
- ❗ Cache doesn’t survive reboots
- Memcached support SASL authentication
- Use cases
- Quick retrieval of objects from memory
- Cache often accessed objects
- Most popular in-memory key-value store
- Super low latency (sub ms)
- Read Scaling using Read Replicas
- Redis Clustering = Collection of one or more cache nodes
- One of the nodes is a read/write primary node.
- All other nodes in the shard are read-only replicas.
- Cache survive reboots by default (persistent)
- 💡 Use-cases: User sessions, Leaderboard (for gaming) with Redis Sorted Sets, Distributed states, Relieve pressure on databases (such as RDS), messages with Redis Pub/Sub, recommendation data with Redis Hashes
- Availability: Multi-AZ with Auto-Failover and enhanced robustness
- Cluster mode -> more persistence and robustness with specified number of read replicas.
- Sharding through clustering
- Network: Deploy into subnet, set preferred availability zone(s), security group
- Encryption at rest (KMS) and in-transit (using SSL)
- Redis support Redis AUTH (username / password with
- Import data to cluster through seeding RDB file from S3
- Automatic back-up
- Persistence by snapshotting your Redis data using the Backup and Restore feature
Redis vs Memcached
||Supported through snapshots
||Each node => Different partition
||1 master and read replicas of it
||Snapshots, replication, transactions, pub/sub, lua scripting, geospatial support
Licenses and Attributions