Nhiều truy vấn lặp đi lặp lại cùng một kết quả; lưu kết quả vào bộ nhớ đệm (cache) in-memory giúp phản hồi nhanh hơn và giảm tải cho database.

ElastiCache là dịch vụ in-memory data store được quản lý hoàn toàn (fully managed), độ trễ dưới một mili giây. Mẫu sử dụng phổ biến nhất là cache-aside (AWS gọi là lazy loading): ứng dụng truy vấn cache trước; nếu không có dữ liệu (cache miss), ứng dụng đọc từ database rồi ghi kết quả vào cache kèm TTL. Mẫu write-through bổ sung: mỗi khi ghi vào database, ứng dụng cập nhật luôn cache. Trong cả hai mẫu, database vẫn là nơi lưu dữ liệu gốc. Thử sáu tình huống của MFTECH:

ElastiCache phù hợp với hai loại tải: tải đọc lớn (cùng một dữ liệu được truy vấn lặp lại) và tính toán tốn tài nguyên (kết quả đòi hỏi nhiều tài nguyên để tính, ví dụ bảng xếp hạng). ElastiCache không giải quyết tải ghi lớn, không thực thi JOIN phức tạp và không thực hiện ETL. Cache node lưu dữ liệu trong bộ nhớ và sao chép sang replica bất đồng bộ, nên giao dịch như đơn mua hàng không được ghi vào cache thay cho database: khi đỉnh tải ghi làm database timeout, dùng Amazon SQS queue để hấp thụ đỉnh tải và RDS Proxy cho connection pooling. ElastiCache for Valkey có tuỳ chọn durability (transactional log Multi-AZ) dành cho trường hợp dùng ElastiCache làm kho dữ liệu chính; cấu hình cache thông thường của MFTECH không bật tuỳ chọn này.

Với dữ liệu trên DynamoDB, có thêm lựa chọn DAX (bài DynamoDB). ElastiCache dùng được cho mọi nguồn dữ liệu: RDS, Aurora, DynamoDB, hoặc chính ElastiCache đóng vai trò session store.

Many queries return the same result again and again; keeping that result in an in-memory cache returns it faster and takes load off the database.

ElastiCache is a fully managed in-memory data store with sub-millisecond latency. The most common usage pattern is cache-aside (AWS calls it lazy loading): the application queries the cache first; if the data is not there (a cache miss), the application reads from the database and writes the result to the cache with a TTL. The write-through pattern adds this: whenever the application writes to the database, it also updates the cache. In both patterns the database remains the system of record. Try six MFTECH scenarios:

ElastiCache fits two kinds of workload: heavy read traffic (the same data is queried repeatedly) and compute-intensive results (results that take a lot of resources to compute, such as leaderboards). ElastiCache does not solve heavy write traffic, does not run complex JOINs and does not perform ETL. Cache nodes keep data in memory and replicate to replicas asynchronously, so transactions such as purchases are not written to the cache instead of the database: when a write peak makes the database time out, use an Amazon SQS queue to absorb the peak and RDS Proxy for connection pooling. ElastiCache for Valkey offers a durability option (a Multi-AZ transactional log) for using ElastiCache as a primary data store; MFTECH’s ordinary cache configuration does not turn it on.

For data on DynamoDB, there is also DAX (DynamoDB lesson). ElastiCache works with any data source: RDS, Aurora, DynamoDB, or ElastiCache itself acting as a session store.