Dưới đây là tóm tắt các ý chính từ bài viết “System Design Pattern: Scaling Writes – How Big Tech Handles Billions of Writes Per Second” của Priya Srivastava:

1. Thách thức: Tại sao việc ghi (writes) khó hơn đọc (reads)

  • Đọc có thể được phân tán qua nhiều bản sao (replicas) và cache; nhưng ghi bắt buộc phải thay đổi “nguồn sự thật” (source of truth) → dễ gặp contention, xung đột và vấn đề nhất quán.
  • Những bottleneck chính khi ghi:
    • Giới hạn I/O đĩa: cơ sở dữ liệu không flush giao dịch đủ nhanh.
    • Khóa (lock) và cạnh tranh key/row: nhiều ghi vào cùng key gây chặn nhau.
    • Băng thông mạng: lượng lớn ghi cùng lúc vượt khả năng mạng.
    • “Hot key”: một vài entity rất “nổi bật” nhận rất nhiều ghi (ví dụ viral post/like) làm nghẽn toàn bộ hệ thống.
  • Ví dụ: một bài reel viral trên Instagram có thể nhận hàng nghìn lượt like/giây – gây áp lực mạnh lên hệ thống ghi.

2. Các chiến lược chính để scale writes (ghi ở quy mô lớn)

Bài viết liệt kê 4 hướng chính, và thường trong thực tế các hệ thống sẽ kết hợp hơn 1 hướng.

2.1 Vertical Scaling & Write Optimization

  • Vertical Scaling (tăng cấp đơn máy/chủ): nâng cấp phần cứng, ổ SSD nhanh hơn, RAM lớn hơn, CPU mạnh hơn.
    Ví dụ: Reddit chuyển từ HDD sang SSD cải thiện ~4× trước khi shard.
    Instagram trước khi sharding đã tận dụng MySQL lớn với SSD-backed volume.
  • Tối ưu DB cấp thấp: chọn engine phù hợp với pattern ghi, tinh chỉnh cấu hình như WAL, index, batch insert, v.v.
    • Ví dụ: dùng OLTP (MySQL/PostgreSQL) nếu cần transactional; dùng LSM-tree DB (Cassandra, RocksDB) cho throughput lớn.
    • Hoặc dùng hệ thống log-structured (ví dụ Kafka, ClickHouse) cho append-only workloads.
  • Ưu/Nhược:
    • Ưu: đơn giản, nhanh để thực hiện, ít refactor.
    • Nhược: có giới hạn vật lý (máy đơn có chừng nào đó); vẫn là điểm đơn nhất (single point of failure); chi phí cao; rồi cũng cần chuyển sang scale ngang (horizontal).

2.2 Sharding & Partitioning

  • Horizontal Sharding: phân tán dữ liệu theo key (ví dụ user_id, region) sang nhiều máy.
    Ví dụ: Instagram phân shard posts theo user_id.
  • Vertical Partitioning: phân tách theo chức năng/tổ hợp dữ liệu (ví dụ: bảng users, bảng payments) ra riêng.
  • Ưu/Nhược:
    • Ưu: phân tải ghi, giảm cạnh tranh khoá, có thể mở rộng gần tuyến tính nếu thiết kế tốt.
    • Nhược: thiết kế phức tạp hơn (chọn shard key, đảm bảo cân bằng, hot-shard), giao dịch xuyên shard khó, vận hành (monitoring, migration, backup) phức tạp.

2.3 Xử lý đột biến (bursts) bằng Queues & Load Shedding

  • Dù shard tốt, vẫn có thể bị traffic spike (đột biến) → cần dùng queue để tách phần chấp nhận ghi ra khỏi phần thực thi ghi.
  • Quy trình: ghi vào queue (ví dụ Kafka, RabbitMQ, SQS) → consumer xử lý ghi vào DB theo nhịp.
    Ví dụ: Strava xếp hàng sự kiện workout trước khi ghi vào DB.
  • Load Shedding: khi queue đầy hoặc hệ thống downstream chậm, có thể:
    • Drop những ghi không quan trọng
    • Giảm chất lượng (graceful degradation)
    • Rate-limit client.
  • Ưu/Nhược:
    • Ưu: tạo bộ đệm (buffer) cho đợt ghi cao, tránh downstream sụp; tăng độ bền và chịu được biến động lớn.
    • Nhược: tăng độ trễ ghi (latency); phức tạp hơn (retry, xử lý thất bại); đảm bảo exactly-once rất khó; debug khó hơn vì ghi không ngay lập tức.

2.4 Batching & Hierarchical Aggregation

  • Không phải mọi ghi cần được persist ngay lập tức; có thể nhóm (batch) nhiều ghi rồi thực thi cùng lúc.
  • Batching: gom nhiều ghi nhỏ vào một transaction lớn. Ví dụ: hệ thống “like” của Facebook batch nhiều lượt trước khi cập nhật DB.
  • Hierarchical Aggregation: thu thập/agg dữ liệu ở nhiều tầng – edge node hoặc cache nội bộ + intermediate service → rồi flush vào core DB theo định kỳ. Ví dụ: TikTok analytics aggregate interactions ở edge rồi mỗi giờ sync vào kho trung tâm.
  • Ưu/Nhược:
    • Ưu: giảm overhead I/O, ghi hiệu quả hơn, lưu lượng viết dự đoán được hơn.
    • Nhược: độ trễ/nhất quán (eventual consistency) có thể không phù hợp ứng dụng cần real-time/strong consistency; tăng độ phức tạp architecture; nếu batch/aggregator fail có thể mất hoặc duplicate ghi.

3. Kết luận & lời khuyên

  • Ghi (writes) là nơi nhiều hệ thống lớn thật sự “gặp vấn đề” chứ không chỉ lý thuyết.
  • Không có “một giải pháp chung” cho tất cả – mỗi hệ thống sẽ dùng kết hợp các chiến lược: vertical → sharding → queue → batching tùy tình huống.
  • Lựa chọn chiến lược phù hợp tại thời điểm đúng: bắt đầu với đơn giản, delay dùng phức tạp cho tới khi cần thiết.
  • Các hệ thống như Instagram, Strava, YouTube… không dựa vào “kiến trúc hoàn hảo từ đầu” mà là các quyết định lặp lại theo dữ liệu thật và giới hạn thực tế.

BÀI VIẾT LIÊN QUANXEM THÊM