Trả lời: Queue là cấu trúc dữ liệu First-In-First-Out (FIFO). Cần dùng để trì hoãn các tác vụ nặng (như gửi email) giúp phản hồi người dùng nhanh hơn.

Trả lời: Là việc lưu trữ tạm thời dữ liệu vào bộ nhớ tốc độ cao (RAM) để truy xuất nhanh hơn thay vì phải tính toán lại hoặc đọc từ DB.

Trả lời: Là cách lưu trữ thông tin của người dùng trên server qua nhiều request khác nhau trong một phiên làm việc.

Trả lời: Là hệ thống lưu trữ dữ liệu In-memory (trong RAM) cực nhanh, thường được dùng để làm Cache, Queue hoặc Session Store.

Trả lời: DB để lưu trữ dữ liệu vĩnh viễn và truy vấn phức tạp. Queue để truyền tin nhắn và xử lý tác vụ theo thứ tự.

Trả lời: Là khoảng thời gian dữ liệu tồn tại trong Cache trước khi tự động bị xóa.

Trả lời: Là dữ liệu cần thiết để thực hiện tác vụ (ví dụ: ID của người dùng cần gửi email).

Trả lời: Hit: Tìm thấy dữ liệu trong Cache. Miss: Không tìm thấy, phải lấy từ nguồn gốc (DB).

Trả lời: Để lưu Session ID ở trình duyệt, giúp Server nhận diện được Client nào đang gửi request.

Trả lời: Sync, Database, Redis, SQS (AWS), Beanstalkd.

Trả lời: RabbitMQ: Message Broker (tin nhắn bị xóa sau khi xử lý). Kafka: Distributed Streaming Platform (tin nhắn lưu lại theo thời gian, hỗ trợ replay).

Trả lời: App check Cache -> Nếu Miss thì đọc DB -> Lưu vào Cache -> Trả về kết quả. Đây là cách dùng Cache phổ biến nhất.

Trả lời: Khi 2 request đồng thời cùng đọc và ghi vào Session, dẫn đến dữ liệu của request này ghi đè lên request kia.

Trả lời: Retries: Thử lại khi job lỗi. Backoff: Tăng dần thời gian chờ giữa các lần thử lại (ví dụ: 1p, 5p, 10p) để tránh làm nghẽn hệ thống.

Trả lời: String, List, Set, Hash, Sorted Set.

Trả lời: RAM đắt hơn ổ cứng, dữ liệu Cache có thể bị sai lệch (Stale data) so với DB, và việc quản lý Invalidation sẽ cực kỳ phức tạp.

Trả lời: Nơi chứa các tin nhắn/job đã thử lại nhiều lần vẫn thất bại, giúp dev dễ dàng kiểm tra và xử lý thủ công sau đó.

Trả lời: Sticky: Ép người dùng luôn vào 1 server cố định (khó scale). Centralized: Lưu Session vào Redis chung (dễ scale ngang).

Trả lời: Publisher gửi tin nhắn tới một Channel. Tất cả các Subscriber đang lắng nghe Channel đó sẽ nhận được tin nhắn cùng lúc.

Trả lời: Dùng duy nhất 1 worker cho 1 queue, hoặc dùng các hệ thống hỗ trợ Sharding/Partitioning theo Key (như Kafka) để đảm bảo 1 Key luôn vào 1 Partition.

Trả lời: Kafka lưu dữ liệu dưới dạng các bản ghi Append-only vào file log trên đĩa. Consumer dùng Offset để quản lý vị trí đã đọc. Điều này cho phép Kafka có throughput cực cao và khả năng đọc lại dữ liệu cũ.

Trả lời: Làm thế nào để biết chính xác khi nào dữ liệu trong Cache đã cũ và cần xóa bỏ. Nếu xóa quá sớm -> tốn tài nguyên DB. Xóa quá muộn -> người dùng thấy dữ liệu sai.

Trả lời: Dùng lệnh SET NX PX (Set if Not Exists with Expiration). Giúp đảm bảo tại 1 thời điểm chỉ có 1 process thực thi một đoạn code nhạy cảm.

Trả lời:

• Penetration: Request vào Key không tồn tại cả trong Cache lẫn DB (Fix: Bloom Filter).
• Breakdown: Hot Key hết hạn, vạn request đổ vào DB (Fix: Mutex lock).
• Avalanche: Hàng loạt Key cùng hết hạn 1 lúc (Fix: Random TTL).

Trả lời: Group giúp chia tải xử lý. Khi thêm/bớt Consumer, Kafka sẽ chia lại các Partition cho các Consumer trong nhóm để đảm bảo cân bằng.

Trả lời:

• At-most-once: Tin nhắn có thể mất nhưng không bao giờ lặp.
• At-least-once: Tin nhắn không bao giờ mất nhưng có thể lặp (phổ biến nhất).
• Exactly-once: Lý tưởng nhất nhưng khó thực hiện nhất, đòi hỏi hỗ trợ từ cả Broker và Application.

Trả lời: RDB: Chụp ảnh nhanh dữ liệu tại thời điểm (nhanh, dễ backup). AOF: Ghi lại mọi lệnh thay đổi dữ liệu (an toàn hơn, dữ liệu đầy đủ hơn).

Trả lời: Dùng Sorted Set (ZSET). Score là thời gian sẽ thực thi (Timestamp). Một worker sẽ dùng lệnh ZRANGEBYSCORE để lấy ra các job có score <= hiện tại để xử lý.

Trả lời: Worker báo cho Broker biết đã xử lý xong tin nhắn. Nếu Worker sập mà chưa gửi Ack, Broker sẽ gửi tin nhắn đó cho Worker khác.

Trả lời: Ưu: Dễ dùng, không cần cài thêm service. Nhược: Gây tải nặng cho DB do liên tục Read/Write/Delete, throughput thấp, không phù hợp cho hệ thống lớn.

Trả lời: Dùng Kafka với nhiều Topic theo Priority (High, Normal, Low). Mỗi Topic có nhiều Partition để scale ngang Consumer. Dùng Redis để lưu trạng thái “Read/Unread” nhanh chóng.

Trả lời: L1: In-memory (Local cache trong App). L2: Distributed Cache (Redis Cluster). L3: Edge Cache (CDN). L4: DB Cache (Query Cache). Cần cơ chế đồng bộ (Pub/Sub) để xóa L1 cache ở các server khác khi dữ liệu đổi.

Trả lời: Dùng Redis Cluster để sharding dữ liệu sang nhiều node. Hoặc dùng giải pháp lai như KeyDB hoặc các dịch vụ Managed (AWS ElastiCache).

Trả lời: Mỗi tin nhắn có một ID duy nhất. Consumer lưu ID này vào DB/Redis với trạng thái “PROCESSED” trong 1 Transaction. Nếu nhận lại ID cũ, bỏ qua ngay lập tức.

Trả lời: Chọn RabbitMQ khi cần routing phức tạp, ưu tiên độ trễ thấp và logic tin nhắn đơn giản. Chọn Kafka khi cần throughput cực lớn, xử lý stream dữ liệu, hoặc cần lưu trữ tin nhắn để phân tích/replay.

Trả lời: Dùng Redis Global Datastore hoặc đồng bộ Session qua Database toàn cầu (như DynamoDB/CosmosDB). Tuy nhiên tốt nhất là thiết kế ứng dụng theo hướng hoàn toàn Stateless dùng JWT.

Trả lời: Khi tốc độ Producer đẩy tin quá nhanh mà Consumer không kịp xử lý. Xử lý: Tăng số lượng Consumer, dùng buffer lớn hơn, hoặc yêu cầu Producer giảm tốc độ (Flow control).

Trả lời: Mọi thay đổi trạng thái được lưu thành một chuỗi các Event trong Kafka. Trạng thái hiện tại được xây dựng lại bằng cách “diễn” lại các event. Giúp hệ thống có khả năng Audit và phục hồi dữ liệu tại bất kỳ thời điểm nào.

Trả lời: Khi 1 Partition chứa quá nhiều dữ liệu do Key không phân bổ đều. Giải pháp: Thay đổi thuật toán băm Key, thêm Salt vào Key, hoặc tăng số lượng Partition.

Trả lời: Ghi dữ liệu vào DB và ghi tin nhắn vào bảng Outbox trong CÙNG 1 Transaction. Một process riêng sẽ đọc bảng Outbox và đẩy vào Queue. Đảm bảo tính nhất quán giữa DB và Queue.

Xử lý: Kiểm tra Log của Supervisor, dùng strace để xem process đang làm gì, kiểm tra các timeout của kết nối DB/Redis bên trong Job. Thêm các dòng log info ở đầu và cuối hàm handle.

Xử lý: 1. Chặn bớt traffic (Rate limit). 2. Khởi động lại Redis. 3. Warm-up cache bằng cách nạp lại các key quan trọng nhất một cách thủ công. 4. Mở lại traffic dần dần.