Harbor

Tổng quan công nghệ

Bảng tra nhanh nhu cầu, công nghệ phù hợp và khi nào nên dùng, kèm link tới bài chi tiết của từng công nghệ trong khoá.

7 phút đọcBắt đầu nhanh

Chọn công nghệ theo nhu cầu

Trong phỏng vấn, bạn được chấm ở lý do chọn công nghệ nhiều hơn ở tên công nghệ. "Em dùng Kafka" không có giá trị. "Em cần giữ thứ tự sự kiện theo từng đơn và cho ba service đọc lại độc lập, nên em dùng Kafka với khoá partition là orderId" mới là câu trả lời. Grokking nhấn mạnh nên hỏi vì sao chọn thành phần này thay vì thành phần khác, và bàn trade-off hơn là chi tiết cài đặt.1

Cách tiếp cận của khoá: bắt đầu từ nhu cầu, chọn công cụ đơn giản nhất đáp ứng được, và biết ngưỡng mà công cụ đó bắt đầu không đủ. Mọi con số năng lực trong các bài công nghệ đều là ước lượng để tính nhẩm (quy tắc ước lượng của khoá học, cần load test).2

Bảng tra nhanh

Nhu cầuCông nghệKhi nào dùng
Dữ liệu quan hệ, transaction, ràng buộcPostgreSQLMặc định cho phần lớn bài. Một node chịu vài nghìn QPS đơn giản và khoảng 1–2 TB
Cache, bộ đếm, khoá phân tán, rate limit, leaderboardRedisCần độ trễ dưới 1 ms, khoảng 100.000 thao tác/s mỗi node
Hàng đợi sự kiện, giữ thứ tự, đọc lại lịch sửKafkaThông lượng lớn, nhiều consumer độc lập. Ở mức nhỏ dùng SQS hoặc BullMQ trước
Tìm kiếm full-text, lọc nhiều trườngElasticsearchTìm theo từ khoá, gợi ý, aggregation. Không dùng làm nguồn dữ liệu chính
Ghi rất nhiều, đọc theo khoá, nhiều regionCassandraHàng chục nghìn lượt ghi/s trở lên, truy vấn biết trước
Key-value managed, scale tự độngDynamoDBTruy cập theo khoá, muốn ít vận hành, chạy trên AWS
Quy trình dài nhiều bước, cần retry và bù trừTemporalĐặt hàng, thanh toán, onboarding nhiều bước có thể lỗi giữa chừng
Điểm vào chung cho API: auth, rate limit, routingAPI GatewayCó nhiều service phía sau, cần chính sách chung
Xử lý luồng sự kiện có trạng thái, cửa sổ thời gianFlinkĐếm theo phút, phát hiện gian lận, top K gần realtime
Điều phối, bầu leader, cấu hình phân tánZooKeeperCần đồng thuận giữa nhiều node. Thường đã có sẵn trong hạ tầng khác
Tìm điểm gần một vị tríTìm kiếm gầnGọi xe, giao hàng, tìm quán. Geohash, quadtree, Redis GEO, PostGIS
Tìm theo ngữ nghĩa, embeddingVector databaseTìm kiếm tương tự, RAG cho chatbot, gợi ý
Metric, dữ liệu theo thời gianTime-series databaseGiám sát hệ thống, dữ liệu cảm biến, giá theo thời gian
Đếm gần đúng trên dữ liệu khổng lồCấu trúc dữ liệu big dataBloom filter, HyperLogLog, Count-Min Sketch khi đếm chính xác quá tốn
Đồng bộ thay đổi từ DB sang hệ khácChange data captureCập nhật search index, cache, data warehouse mà không ghi kép

Cột "Khi nào dùng" là tóm tắt của khoá học. Các ý có sách trong thư viện: Grokking nêu QPS tham khảo của MySQL khoảng 1.000, key-value store khoảng 10.000, cache server 100.000 đến 1 triệu (phụ thuộc loại truy vấn và cấu hình);3 full-text search dựa trên inverted index;4 sorted set và các cấu trúc dữ liệu của Redis phục vụ đếm, xếp hạng;5 API gateway là điểm vào chung của client tới các service;6 saga điều phối quy trình nhiều bước bằng giao dịch bù trừ;7 đọc log giao dịch của database để phát sự kiện là cách đồng bộ không ghi kép.8 Các công nghệ cụ thể sau đây chưa có sách trong thư viện: Flink, Temporal, vector database, time-series database, HyperLogLog và Count-Min Sketch.9 Bloom filter có trong chương cache phân tán của Grokking.10

Nhóm công nghệ cần biết trước

Bốn công nghệ xuất hiện ở hầu hết bài thiết kế. Nên đọc kỹ trước khi luyện bài.

  • PostgreSQL: replication, read replica, partition, transaction isolation, khoá dòng. Đây là lựa chọn mặc định cho mức 1 và 2.
  • Redis: cấu trúc dữ liệu, Lua script, TTL, Redis Cluster, cách tính RAM.
  • Kafka: topic, partition, consumer group, offset, giao ít nhất một lần.
  • Elasticsearch: inverted index, shard, cách đồng bộ từ database chính.

Nhóm công nghệ theo bài

Các công nghệ còn lại nên đọc khi bài thiết kế cần tới.

Công nghệBài thiết kế dùng nhiều
Cassandra, DynamoDBỨng dụng chat, Ad click aggregator
TemporalHệ thống thanh toán, Giao hàng nội thành
FlinkTop K, Ad click aggregator
Tìm kiếm gầnGọi xe, Yelp
Vector databaseỨng dụng chat với AI
Time-series databaseGiám sát metric, Theo dõi giá
Change data captureTìm kiếm bài viết, Booking và tracking container
API GatewayRate limiter

Managed hay tự vận hành

Ở mức Khởi đầu và Tăng trưởng, gần như luôn chọn dịch vụ managed (khuyến nghị của khoá học, không phải của sách):11 Postgres trên RDS hoặc Cloud SQL, Redis managed, SQS hoặc Pub/Sub thay cho Kafka. Một đội nhỏ không nên tự vận hành cluster. Grokking cũng nhắc mỗi lựa chọn có chi phí tiền và độ phức tạp kỹ thuật khác nhau cần cân nhắc.12 Chi phí managed cao hơn tính theo máy, nhưng rẻ hơn nhiều nếu tính cả thời gian kỹ sư và rủi ro sự cố.

Tự vận hành chỉ hợp lý ở mức Quy mô lớn, khi có đội platform riêng và hoá đơn managed đã đủ lớn để thuê người tối ưu.

Trong phỏng vấn: nói rõ bạn chọn managed hay tự vận hành và vì sao. Câu "ở mức này em dùng SQS, khi lượng sự kiện vượt vài chục nghìn mỗi giây và cần đọc lại lịch sử thì chuyển sang Kafka" cho thấy bạn hiểu cả công nghệ lẫn thực tế vận hành.

Lỗi hay gặp

Sai lầm hay gặp: thêm một công nghệ cho mỗi vấn đề nhỏ. Mỗi thành phần mới là thêm một thứ phải giám sát, backup, nâng cấp. Nếu Postgres với một index tốt đã đủ, đừng thêm Elasticsearch. Grokking cũng chỉ ra rằng chọn thành phần phải cân nhắc chi phí và độ phức tạp.12

  • Dùng Elasticsearch hoặc Redis làm nguồn dữ liệu chính khi dữ liệu không được phép mất.
  • Chọn Cassandra nhưng chưa biết truy vấn chính, rồi phải quét toàn bảng.
  • Nhắc Kafka cho hệ thống chỉ vài chục sự kiện mỗi giây.
  • Không nêu được giới hạn của công nghệ mình chọn, ví dụ RAM của Redis hay kích thước shard của Elasticsearch.

Nguồn trích dẫn

  1. Grokking Modern System Design · ch.2 System Design Interviews · bài "How to Prepare for Success", mục "Ask why a system works" và "The right direction". ↩

  2. Quy tắc ước lượng của khoá học, xem bài Chọn server. Không phải số liệu trích từ sách. ↩

  3. Grokking Modern System Design · ch.5 Back-of-the-envelope Calculations · bài "Put Back-of-the-envelope Numbers in Perspective", bảng "Important Rates". ↩

  4. Grokking Modern System Design · ch.21 Distributed Search · mục "Inverted index". ↩

  5. Redis in Action · ch.1 Getting to know Redis, và ch.3 Commands in Redis · mục "Sorted sets". ↩

  6. Microservices Patterns (file .zip, tải về giải nén) · ch.8 External API patterns · §8.2 The API gateway pattern. ↩

  7. Microservices Patterns (file .zip, tải về giải nén) · ch.4 Managing transactions with sagas · mục "Pattern: Saga" và "Orchestration-based sagas". ↩

  8. Microservices Patterns (file .zip, tải về giải nén) · ch.3 · mục "Transaction log tailing" (publishing events by applying the transaction log tailing pattern). ↩

  9. Chưa có nguồn trong thư viện: thư viện không có sách về Flink, Temporal, vector database, time-series database, HyperLogLog hay Count-Min Sketch; các dòng tương ứng trong bảng chỉ nêu mục đích cơ bản, các bài chi tiết ghi rõ phần chưa có nguồn. ↩

  10. Grokking Modern System Design · ch.16 Distributed Cache · phần nhắc tới Bloom filter. ↩

  11. Chưa có nguồn trong thư viện: không sách nào so sánh managed với tự vận hành theo quy mô đội; đây là quan điểm của khoá học. ↩

  12. Grokking Modern System Design · ch.2 System Design Interviews · bài "How to Perform Well", mục "Discuss trade-offs". ↩ ↩2

Đọc thêm trong thư viện
Grokking · ch.2 System Design Interviews ↗Grokking · ch.9 Databases ↗Grokking · ch.17 Distributed Messaging Queue ↗Grokking · ch.21 Distributed Search ↗Microservices Patterns · ch.3 Interprocess communication ↗Microservices Patterns · ch.4 Managing transactions with sagas ↗Microservices Patterns · ch.8 External API patterns ↗Redis in Action · ch.1 Getting to know Redis ↗