Nắm vững 50 khái niệm cốt lõi về thiết kế hệ thống (System Design) chỉ trong một bài viết: từ Scaling, CAP/PACELC, Sharding đến Caching, Message Queues, Reliability Patterns và Security. Đây là bản hướng dẫn thực dụng, ngắn gọn dành cho người mới bắt đầu và các ứng viên đang chuẩn bị phỏng vấn kiến trúc hệ thống.

Khi mới bắt đầu tìm hiểu về System Design, rào cản lớn nhất không nằm ở độ khó của khái niệm, mà là việc tìm kiếm một nguồn tài liệu tổng hợp, dễ hiểu và có hệ thống. Đó là lý do tại sao một lộ trình toàn diện bao quát mọi khía cạnh cốt lõi sẽ là “vũ khí” thay đổi cuộc chơi của bạn.

Trong bài viết này, chúng ta sẽ cùng đi qua 50 khái niệm quan trọng nhất. Hãy coi đây là “cuốn từ điển bỏ túi” để hiểu cách các hệ thống thực tế vận hành, mở rộng (scale), duy trì độ tin cậy và xử lý dữ liệu ở quy mô lớn.

I. Core Architecture Principles (Các nguyên lý kiến trúc cốt lõi)

Vertical vs Horizontal Scaling

Vertical Scaling (Scale-up): Là việc nâng cấp tài nguyên cho một máy chủ duy nhất (tăng CPU, RAM hoặc ổ cứng SSD tốc độ cao).

Horizontal Scaling (Scale-out): Là việc bổ sung thêm nhiều máy chủ vào hệ thống và phân phối tải công việc giữa chúng.

Phân tích: * Vertical dễ triển khai nhưng nhanh chóng chạm ngưỡng giới hạn phần cứng và chi phí tăng phi mã theo cấp số nhân. Horizontal phức tạp hơn vì đòi hỏi phải có bộ cân bằng tải (Load Balancer), các dịch vụ không lưu trạng thái (Stateless Services) và cơ chế chia sẻ dữ liệu.

Dễ hiểu hơn: Vertical là nâng cấp một siêu anh hùng trở nên mạnh hơn; Horizontal là xây dựng cả một biệt đội anh hùng để cùng tác chiến.

CAP Theorem (Định lý CAP)

Định lý CAP khẳng định rằng trong một hệ thống phân tán, khi xảy ra hiện tượng phân đoạn mạng (Network Partition), chúng ta chỉ có thể chọn tối đa hai trong ba yếu tố:

• Consistency (Tính nhất quán): Mọi node đều thấy dữ liệu giống nhau tại cùng một thời điểm.
• Availability (Tính sẵn sàng): Hệ thống luôn phản hồi mọi yêu cầu, ngay cả khi dữ liệu có thể đã cũ (stale).
• Partition Tolerance (Tính chịu lỗi phân đoạn): Hệ thống vẫn hoạt động dù mạng lưới kết nối giữa các node bị gián đoạn.

Vì môi trường mạng thực tế luôn có rủi ro bị ngắt quãng (P), bạn buộc phải đánh đổi giữa CP System: Consistency + Partition Tolerance (Ưu tiên Nhất quán) và AP System: Availability + Partition Tolerance (Ưu tiên Sẵn sàng) tùy thuộc vào bài toán nghiệp vụ.

PACELC Theorem (Định lý PACELC)

PACELC mở rộng CAP:

• Nếu Partition xảy ra (P): chọn Availability (A) hoặc Consistency (C).
• Else (E), khi mạng bình thường: chọn Latency (L) hoặc Consistency (C).

=> Ngay cả khi hệ thống hoạt động bình thường, bạn vẫn phải đánh đổi:
đọc nhanh nhưng eventual consistency vs đọc chậm nhưng strongly consistent.

Điều này lý giải vì sao:

• Một số database nhanh nhưng có độ trễ lan truyền (eventually consistent).
• Một số database đảm bảo chính xác tuyệt đối nhưng latency cao.

ACID vs BASE

• ACID (Atomicity, Consistency, Isolation, Durability): Tập trung vào tính giao dịch nghiêm ngặt. Phù hợp cho hệ thống tài chính, ngân hàng, kho bãi – nơi sai sót dữ liệu là không thể chấp nhận.
• BASE (Basically Available, Soft state, Eventual consistency): Ưu tiên tính sẵn sàng cao và khả năng phản hồi nhanh. Hệ thống BASE chấp nhận tình trạng dữ liệu không nhất quán tạm thời nhưng sẽ tự động đồng bộ và chính xác sau một khoảng thời gian (Eventual Consistency).

Trong thực tế, nhiều kiến trúc kết hợp cả hai: Sử dụng ACID cho các luồng xử lý dòng tiền và BASE cho các tính năng như Newsfeed hay Analytics.

Throughput vs Latency (Lưu lượng vs Độ trễ)

• Throughput: Số lượng yêu cầu mà hệ thống có thể xử lý trong một đơn vị thời gian (ví dụ: Requests Per Second – RPS).
• Latency: Thời gian hoàn thành một yêu cầu cụ thể từ lúc bắt đầu đến khi kết thúc.

Bạn có thể tăng Throughput bằng cách xử lý song song, nhưng điều này có thể làm tăng Latency nếu các hàng đợi (queues) bị quá tải. Một thiết kế tốt là sự cân bằng giữa lưu lượng xử lý đủ lớn cho giờ cao điểm và độ trễ thấp để đảm bảo trải nghiệm người dùng mượt mà.

Amdahl’s Law (Định luật Amdahl)

Định luật này chỉ ra rằng việc cải thiện hiệu suất tổng thể nhờ song song hóa bị giới hạn bởi phần công việc không thể chạy song song (phần tuần tự).

Nếu 20% hệ thống của bạn bắt buộc phải xử lý tuần tự, thì dù bạn có thêm bao nhiêu máy chủ đi nữa, tốc độ tối đa cũng không thể vượt quá ngưỡng giới hạn của 20% đó. Điều này nhắc nhở các kiến trúc sư phải luôn tìm kiếm và giải quyết các bottleneck (nút thắt cổ chai) thay vì chỉ thêm phần cứng một cách mù quáng.

Strong vs Eventual Consistency (Nhất quán mạnh vs Nhất quán cuối cùng)

Strong Consistency: Người dùng luôn thấy dữ liệu mới nhất ngay sau khi ghi. Dễ lập trình nhưng làm tăng độ trễ và giảm tính sẵn sàng khi có lỗi.

Eventual Consistency: Các bản cập nhật sẽ lan truyền dần dần. Các node có thể trả về dữ liệu lệch nhau trong tích tắc. Đây là lựa chọn lý tưởng cho các hệ thống quy mô lớn như Facebook Timeline hay bộ đếm Like, nơi sự chính xác tuyệt đối từng mili giây không quá quan trọng.

Chọn mô hình dựa trên user expectation của ứng dụng.

Stateful vs Stateless Architecture

• Stateful: lưu session hoặc context trong instance ứng dụng.
  → khó scale, khó failover.
• Stateless: mọi request độc lập; state đưa ra ngoài (Redis, DB).
  → scale-out dễ dàng, phù hợp cloud-native.

Hệ thống hiện đại ưu tiên stateless để hỗ trợ auto-scaling, rolling updates, multi-zone.

Microservices vs Monoliths

Monolith

• Một khối ứng dụng lớn.
• Đơn giản khi bắt đầu, dễ debug.
• Nhưng khó scale theo service, CI/CD nặng, coupling cao.

Microservices

• Chia nhỏ thành nhiều service độc lập.
• Cho phép team phát triển độc lập, scale từng phần.
• Nhưng phức tạp: distributed tracing, network failures, data consistency, versioning.

Hầu hết hệ thống tốt đều bắt đầu từ monolith rồi tách dần khi hệ thống đủ lớn và có “động lực đau đớn”.

Serverless Architecture

Serverless cho phép chạy function mà không quản lý server.

• Trả tiền theo mức sử dụng.
• Scale tự động.
• Lý tưởng cho event-driven: webhook, background task, xử lý batch nhẹ.

Trade-offs:

• Cold start
• Giới hạn thời gian chạy
• Chi phí cao khi traffic lớn

Hãy xem serverless như “functions-as-a-service” cho glue logic và micro-workload.

II. Networking and Communication (Mạng & Giao tiếp trong hệ phân tán)

Load Balancing (Cân bằng tải)

Load balancing phân phối lưu lượng đến nhiều server để tránh tình trạng một server bị quá tải. Điều này cải thiện reliability và performance, vì khi một server gặp sự cố, hệ thống vẫn hoạt động bình thường.

Load balancer có thể là phần cứng hoặc phần mềm, thường hỗ trợ health check để tự động bỏ qua các instance không khỏe.

Trong phỏng vấn system design, load balancer là “viên gạch đầu tiên” khi bạn nói về horizontal scaling.

Load Balancing Algorithms (Các thuật toán Cân bằng tải)

Một số thuật toán load balancing phổ biến:

• Round Robin – chuyển request lần lượt qua từng server; dễ triển khai.
• Least Connections – gửi request đến server có ít kết nối active nhất; phù hợp khi request nặng nhẹ khác nhau.
• IP Hash – hash dựa trên IP client để duy trì session stickiness đơn giản.

Việc chọn thuật toán ảnh hưởng trực tiếp đến fairness, latency và trải nghiệm người dùng.

Reverse Proxy vs Forward Proxy

• Reverse Proxy
  Đứng trước backend, đại diện backend nói chuyện với client.
  Hỗ trợ TLS termination, caching, compression, routing.
• Forward Proxy
  Đứng trước client, đại diện client truy cập internet.
  Dùng để kiểm duyệt nội dung, caching hoặc bảo mật mạng nội bộ.

Reverse proxy giống quầy lễ tân che toàn bộ nội thất bên trong.
Forward proxy giống cổng kiểm soát bạn phải đi qua trước khi ra internet.

Hiểu rõ hai loại proxy rất quan trọng khi nói về API Gateway và enterprise proxy.

API Gateway

API Gateway là dạng reverse proxy chuyên dụng, đóng vai trò “single entry point” cho toàn bộ API trong kiến trúc microservices.

Nó xử lý:

• routing đến đúng service
• rate limiting
• auth
• logging
• đôi khi response transformation

Điều này giảm tải cho client vì client chỉ cần gọi một endpoint duy nhất.

Lưu ý: nhồi quá nhiều logic vào gateway → biến thành “mini monolith”, gây bottleneck. Gateway tốt là gateway “mỏng”.

CDN (Content Delivery Network)

CDN là mạng các server phân tán địa lý, dùng để cache nội dung tĩnh (image, video, script) gần người dùng hơn.

Khi client request, CDN sẽ:

• route đến node gần nhất
• trả file từ cache
• giảm tải origin server
• giảm latency đáng kể

CDN là bắt buộc cho ứng dụng có người dùng toàn cầu.

Hãy xem CDN như những “bản sao local” của file nặng được rải đều khắp thế giới.

DNS (Domain Name System)

DNS ánh xạ domain name → IP address.

Khi bạn nhập URL, trình duyệt sẽ truy vấn DNS để lấy địa chỉ IP thực của server.

DNS có nhiều lớp caching (browser, OS, resolver, ISP), giúp tăng tốc độ truy vấn. DNS cũng có thể thực hiện simple load balancing bằng cách trả về nhiều IP.

Hiểu DNS giúp giải thích:

• vì sao thay đổi domain mất thời gian propagate
• vì sao nhiều sự cố bắt nguồn từ cấu hình DNS sai

TCP vs UDP

Đây là hai giao thức truyền tải cơ bản nhất:

TCP (Transmission Control Protocol): Tin cậy, hướng kết nối. Đảm bảo dữ liệu đến đúng thứ tự và không bị lỗi thông qua cơ chế xác nhận (ACK) và truyền lại. Phù hợp cho web (HTTP), email, truyền file.

UDP (User Datagram Protocol): Không kết nối, không đảm bảo thứ tự hay độ tin cậy nhưng cực nhanh và nhẹ. Phù hợp cho streaming video, voice chat hoặc chơi game online – nơi việc mất vài gói tin không quan trọng bằng độ trễ.

TCP = thư bảo đảm.
UDP = postcard gửi nhanh, mất vài cái cũng được.

HTTP/2 và HTTP/3 (QUIC)

HTTP/2: Giới thiệu cơ chế Multiplexing (đa luồng), cho phép nhiều request cùng chia sẻ một kết nối TCP duy nhất, giúp giảm overhead và hỗ trợ nén header.

HTTP/3: Chạy trên giao thức QUIC (xây dựng dựa trên UDP). Nó giúp thiết lập kết nối cực nhanh và cải thiện hiệu năng đáng kể trên các mạng không ổn định (như wifi yếu hoặc 4G/5G).

Cả hai tập trung giảm latency và tối ưu connection management.

Ý chính: ít handshake hơn – tận dụng tối đa một connection.

gRPC vs REST

REST: Sử dụng HTTP với dữ liệu dạng JSON. Dễ đọc, dễ hiểu, là tiêu chuẩn cho các API công khai (Public API).

gRPC: Sử dụng HTTP/2 và dữ liệu được mã hóa nhị phân (Protocol Buffers). Nó nhanh hơn, nhẹ hơn và hỗ trợ truyền tải dữ liệu hai chiều (bidirectional streaming).

Best practice: Thường dùng gRPC cho giao tiếp nội bộ giữa các Microservices và dùng REST cho các client bên ngoài.

WebSocket và Server-Sent Events (SSE)

• WebSocket: kết nối full-duplex → hai chiều
  Phù hợp chat, multiplayer, live collaboration.
• SSE: server → client một chiều
  Dễ triển khai, dùng cho live score, notification, dashboard update.

Cả hai giải quyết vấn đề real-time mà HTTP truyền thống không tối ưu.

Long Polling

Long polling là kỹ thuật “giả lập” thời gian thực trên HTTP truyền thống. Client gửi một request và server sẽ giữ kết nối đó mở cho đến khi có dữ liệu mới hoặc hết thời gian chờ (timeout). Ngay khi nhận được phản hồi, client sẽ gửi ngay một request mới.

Tuy kém hiệu quả hơn WebSocket nhưng nó dễ triển khai và hoạt động tốt qua các hệ thống firewall/proxy cũ.

Gossip Protocol (Giao thức tin đồn)

Trong một hệ thống phân tán, Gossip Protocol giúp các node chia sẻ thông tin bằng cách trao đổi định kỳ với một vài node ngẫu nhiên khác. Sau một thời gian, thông tin sẽ lan truyền khắp hệ thống giống như “tin đồn” trong xã hội.

Đây là cách cực kỳ hiệu quả và chịu lỗi tốt để quản lý trạng thái của các cụm máy chủ lớn (cluster) mà không cần một server điều phối trung tâm.

Ứng dụng:

• cluster membership
• health check
• distributed metadata
• configuration spreading

Không cần trung tâm điều phối → phù hợp cluster lớn, node vào/ra liên tục.

Gossip = eventually consistent, fault tolerant, scalable.

III. Database and Storage Internals (Bên trong hệ thống lưu trữ & cơ sở dữ liệu)

Sharding (Data Partitioning – phân mảnh dữ liệu)

Sharding chia dữ liệu thành nhiều phần và lưu trên nhiều máy khác nhau. Mỗi shard chứa một tập con của dữ liệu tổng thể. Một số chiến lược phổ biến:

• Range-based sharding: chia theo khoảng (VD: user_id 1–1M, 1M–2M).
• Hash-based sharding: hash key → shard, phân phối đồng đều hơn.
• Directory-based sharding: dùng bảng lookup ánh xạ key → shard.

Mục tiêu chính:

• Mở rộng dung lượng lưu trữ,
• Tăng throughput,
• Tránh một database quá tải (giant DB node).

Thách thức lớn nhất là chọn shard key tránh hotspot (một shard nhận toàn traffic).
Và khi cụm tăng trưởng, resharding (di chuyển dữ liệu giữa shard) trở thành vấn đề vận hành phức tạp.

Replication Patterns (Master–Slave, Master–Master)

Replication tạo nhiều bản sao dữ liệu trên các node khác nhau.

Master–Slave (Primary–Replica)

• Một node xử lý write.
• Các node khác replicate dữ liệu và phục vụ read.

Master–Master (Multi-Primary)

• Nhiều node chấp nhận write.
• Cần cơ chế conflict resolution.

Replication cải thiện:

• read scalability
• availability

Nhưng gây khó khăn về consistency, đặc biệt khi nhiều node chấp nhận ghi.

Trong phỏng vấn, bạn phải giải thích:

• replication lag ảnh hưởng read như thế nào
• failover diễn ra ra sao khi master chết

Consistent Hashing

Consistent hashing phân phối key lên các node sao cho khi node thêm/bớt, chỉ cần di chuyển một phần nhỏ dữ liệu.

Nguyên lý:

• Node và key được đặt lên một vòng logic (hash ring).
• Một key thuộc về node tiếp theo theo chiều kim đồng hồ trên vòng.

Nhờ vậy, cluster thêm máy hoặc mất máy → không phải phân phối lại dữ liệu toàn bộ.

Đây là kỹ thuật quan trọng trong distributed cache (Redis Cluster, Memcached), Cassandra, Dynamo.

Database Indexing (B-Tree, LSM-Tree)

Index giúp tăng tốc truy vấn bằng cách tổ chức dữ liệu để lookup nhanh hơn.

B-Tree

• Dữ liệu được sắp xếp
• Truy vấn range cực nhanh
• Dùng trong hầu hết relational DB (MySQL, Postgres)

LSM-Tree

• Ghi vào memory trước, rồi flush dạng sorted files (SSTable) xuống disk
• Write cực nhanh, nhưng read phức tạp hơn
• Dùng trong NoSQL (Cassandra, LevelDB, RocksDB)

Trade-off:

• B-Tree → tốt cho read-heavy
• LSM → tốt cho write-heavy

Điểm quan trọng:
Index là một cấu trúc riêng cần update mỗi lần ghi, vì vậy quá nhiều index làm insert chậm đáng kể.

Write-Ahead Logging (WAL)

WAL ghi các thay đổi vào log trước khi áp dụng lên dữ liệu thực.

Lợi ích:

• Nếu crash giữa chừng, database có thể replay log để khôi phục trạng thái nhất quán.
• Đảm bảo durability & atomicity.
• Cho phép replication từ log stream (VD: PostgreSQL replication).

Nếu không có WAL, crash có thể làm database rơi vào trạng thái nửa cập nhật, dẫn đến corruption.

Normalization vs Denormalization

Normalization

Tổ chức dữ liệu để:

• giảm dư thừa
• tránh inconsistency
• tuân theo 1NF, 2NF, 3NF…

Denormalization

Cố tình nhân bản dữ liệu để:

• tăng tốc đọc
• giảm join
• giảm latency ở hệ thống scale lớn

Ví dụ: lưu cả username trong bảng posts để tránh join với bảng users.

Kỹ năng quan trọng:

Biết khi nào denormalize và đảm bảo consistency ở mức cho phép.

Polyglot Persistence (Lưu trữ đa dạng)

Polyglot persistence nghĩa là dùng nhiều loại database trong cùng hệ thống, mỗi loại tối ưu cho một mục tiêu:

• relational DB → transactions
• document DB → log, event store, flexible schema
• key-value store → caching
• graph DB → mối quan hệ phức tạp

Thay vì ép mọi thứ vào một DB duy nhất, kiến trúc chọn “đúng công cụ cho đúng việc”.

Trade-off:

• tăng complexity vận hành
• yêu cầu đội ngũ có đa kỹ năng DB

Bloom Filters(Bộ lọc Bloom)

Bloom Filter là một cấu trúc dữ liệu cực kỳ tiết kiệm không gian, dùng để trả lời nhanh câu hỏi: “Một phần tử có tồn tại trong tập hợp này không?”.

• Nếu kết quả là Không: Chắc chắn phần tử đó không tồn tại.
• Nếu kết quả là Có: Có khả năng phần tử đó tồn tại (có tỉ lệ dương tính giả nhỏ).

Ứng dụng:

• database tránh đọc disk không cần thiết
• cache tránh query key không tồn tại
• distributed storage giảm traffic lookup

Bloom filter = “người gác cổng” trả lời:
“chắc chắn không có” hoặc “có thể có”.

Vector Databases

Vector database lưu và truy vấn vector embeddings – biểu diễn số của text, ảnh, âm thanh.

Thay vì so sánh equality, chúng dùng:

• cosine similarity
• Euclidean distance
• inner product

Dùng cho:

• search theo ngữ nghĩa
• recommendation
• AI assistant
• document similarity

Trong phỏng vấn, bạn chỉ cần nắm:

Vector DB hỗ trợ nearest neighbor search trên dữ liệu nhiều chiều (high-dimensional 

vectors).

IV. Reliability and Fault Tolerance (Độ tin cậy & chịu lỗi trong hệ phân tán)

Rate Limiting (Giới hạn lưu lượng)

Rate limiting kiểm soát số lượng request mà một user, IP hoặc API key có thể gửi trong một khoảng thời gian.

Mục đích:

• bảo vệ hệ thống khỏi abuse
• ngăn traffic spike gây overload
• tránh vòng lặp “điên” từ client lỗi

Các chiến lược phổ biến:

• Fixed window
• Sliding window
• Token bucket / Leaky bucket

Rate limit thường được áp dụng ở API Gateway hoặc Load Balancer.

Hãy xem rate limiting như “phanh an toàn” giúp tài nguyên chung không bị phá hỏng.

Circuit Breaker Pattern

Circuit breaker giám sát các call đến service bên ngoài → nếu tỷ lệ lỗi quá cao, nó mở (open):

• Khi open, mọi request mới sẽ fail ngay lập tức, không tiếp tục gọi service đang hỏng.
• Sau thời gian cooldown, circuit breaker chuyển sang half-open và thử vài request.
• Nếu các request thử thành công → đóng (close) và hoạt động lại bình thường.

Mục tiêu:
ngăn một service chậm/chết kéo cả hệ thống sập theo (cascading failure).

Điểm khó: tinh chỉnh threshold, timeout và cooldown sao cho không mở quá sớm hoặc quá muộn.

Bulkhead Pattern

Bulkhead pattern cô lập từng phần của hệ thống để ngăn lỗi lan rộng.

Áp dụng bằng cách:

• tách connection pool
• tách thread pool
• tách cluster theo chức năng

Nếu một bulkhead bị flood traffic → các bulkhead khác vẫn hoạt động bình thường.

Thuật ngữ này xuất phát từ “vách ngăn chống ngập” trên tàu thủy.

Nhắc đến bulkhead trong design discussion thể hiện bạn hiểu về fault isolation và blast radius control.

Retry Patterns & Exponential Backoff

Retry giúp phục hồi từ lỗi tạm thời như timeout hoặc service quá tải.

Exponential backoff:
Mỗi lần retry đợi lâu hơn:
1s → 2s → 4s → 8s …

Kết hợp với jitter (random nhỏ) để tránh thundering herd (tất cả client retry cùng lúc).

Retry không có backoff thường làm outage nặng hơn vì tạo thêm traffic vào service đang gặp sự cố.

Idempotency

Một operation là idempotent nếu thực thi nhiều lần → kết quả vẫn như một lần.

Ví dụ:

• Idempotent: set status = active, PUT /user/123
• Not idempotent: tăng balance, trừ tiền, tạo order mới

Idempotency cực quan trọng khi:

• sử dụng retry
• hệ thống có “at-least-once” delivery
• xử lý payment hoặc giao dịch quan trọng

Nhiều API yêu cầu idempotency key để tránh double-charging.

Trong phỏng vấn, nhớ nhắc đến idempotency khi nói về retry hoặc message queues.

Heartbeat

Heartbeat là tín hiệu định kỳ do service hoặc node gửi để thông báo rằng nó còn sống (liveness) và hoạt động bình thường (health).

Monitoring hoặc coordinator lắng nghe heartbeat:

• nếu không nhận được heartbeat trong thời gian quy định → đánh dấu node down
• kích hoạt failover, autoscaling hoặc replace instance

Heartbeat giống như “nhịp tim” của hệ thống – đơn giản nhưng cực kỳ hiệu quả.

Leader Election (Paxos, Raft)

Leader election là quá trình chọn một node duy nhất để đóng vai trò điều phối viên.

Thuật toán phổ biến:

• Paxos
• Raft (dễ hiểu hơn, dùng rộng rãi trong các database hiện đại)

Leader chịu trách nhiệm:

• quản lý metadata
• điều phối thứ tự ghi (write ordering)
• phân công công việc

Nếu leader hỏng → cluster tự bầu leader mới.

Trong phỏng vấn, bạn chỉ cần biết:

Paxos/Raft đảm bảo consensus → cốt lõi của metadata store, distributed logs, và hệ thống phân tán quan trọng.

Distributed Transactions – SAGA Pattern

Distributed transaction bao gồm nhiều bước trải rộng trên nhiều service/database.

SAGA pattern giải quyết bằng cách:

• chia giao dịch thành chuỗi các local transaction
• mỗi bước có compensating action để rollback khi lỗi
• giao tiếp qua event hoặc orchestrator

Không khóa tài nguyên như ACID multi-node, phù hợp microservices và eventual consistency.

Trade-off:

• Logic phức tạp hơn
• Dễ xảy ra partial failure
• Cần thiết kế bù trừ rõ ràng

Two-Phase Commit (2PC)

2PC cố gắng cung cấp giao dịch atom across nhiều node.

Gồm hai pha:

1. Prepare phase
   Coordinator hỏi các participant: “Có commit được không?”
2. Commit phase
   Nếu tất cả đồng ý → commit
   Nếu ai đó từ chối → rollback

Ưu điểm:

• Strong consistency

Nhược:

• Coordinator chết → hệ thống bị block
• Tốn tài nguyên → không phù hợp hệ thống throughput lớn
• Không scale tốt trong cloud-native

Vì vậy, nhiều hệ thống hiện đại dùng SAGA thay thế cho 2PC ở đường dữ liệu lớn.

V. Caching and Messaging (Bộ nhớ đệm & hệ thống nhắn tin phân tán)

Caching

Caching lưu dữ liệu thường xuyên truy cập trong một lớp lưu trữ nhanh (thường là memory) để giảm latency và giảm tải backend/database.

Các loại cache phổ biến:

• In-process cache (cache nằm trong memory của ứng dụng)
• External key-value store (Redis, Memcached)
• CDN cache (content caching ở edge)

Caching đặc biệt hiệu quả cho:

• workload đọc nhiều (read-heavy)
• các phép tính tốn kém
• dữ liệu ít thay đổi

Nhưng vấn đề khó nhất chính là stale data và cache invalidation.

Có câu nói kinh điển:
“Cache invalidation là một trong những bài toán khó nhất của khoa học máy tính.”

Caching Strategies (Cache Aside, Write Through, Write Back)

Cache Aside (Lazy Loading)

Ứng dụng:

1. đọc cache
2. nếu miss → đọc DB
3. ghi kết quả vào cache

Chiến lược phổ biến nhất cho web API.

Write Through

Ghi vào cache và database cùng lúc.
Ưu: cache luôn đồng bộ với DB.
Nhược: ghi chậm hơn.

Write Back (Write Behind)

Ghi vào cache trước, flush xuống DB sau.
Ưu: tốc độ ghi nhanh.
Nhược: rất rủi ro nếu cache crash → mất dữ liệu chưa flush.

Mỗi strategy cân bằng giữa:

• độ tươi của dữ liệu
• độ phức tạp
• hiệu năng tổng thể

Interviewer rất thích hỏi: “Với scenario X, bạn chọn caching strategy nào – và vì sao?”

Cache Eviction Policies (LRU, LFU, etc.)

Eviction policy quyết định item nào bị loại khỏi cache khi đầy.

LRU – Least Recently Used

Xóa những item không được truy cập gần đây nhất.
Phù hợp khi locality theo thời gian cao.

LFU – Least Frequently Used

Xóa những item ít được truy cập nhất.
Phù hợp khi giá trị dựa vào tần suất truy cập.

Ngoài ra còn:

• FIFO
• Random eviction
• ARC, Hyperbolic caching, CLOCK (trong OS)

Ý chính:

Cache có dung lượng giới hạn → phải giữ lại những item có giá trị cao nhất.

Message Queues (Point-to-Point Messaging)

Message queue cho phép một component gửi message đến component khác mà không cần cả hai online cùng lúc.

Trong mô hình point-to-point:

• message đi vào queue
• một consumer nhận và xóa message khỏi queue
• mỗi message chỉ được xử lý một lần bởi một consumer

Lợi ích:

• decouple sender/receiver
• scale độc lập
• fail độc lập
• hỗ trợ background processing

Ứng dụng thực tế:

• gửi email
• xử lý tác vụ nặng
• batch processing
• async job pipeline

Hãy xem message queue như “todo list” chia sẻ giữa các service.

Pub/Sub (Publish–Subscribe)

Trong mô hình pub/sub:

• publisher gửi message đến topic, không gửi trực tiếp cho từng consumer
• subscriber đăng ký topic và nhận bản sao message phù hợp

Lợi ích:

• broadcast nhiều consumer
• service loosely coupled
• hỗ trợ event-driven architecture

Nhiều consumer có thể xử lý cùng một event theo cách khác nhau:

• logging
• monitoring
• analytics
• notification

Pub/Sub thường xuất hiện trong:

• event sourcing
• activity feed
• event-driven microservices

Dead Letter Queues (DLQ)

Dead letter queue lưu những message không xử lý được sau nhiều lần retry.

Mục đích:

• tránh queue chính bị kẹt vì “poison messages”
• tránh retry vô hạn
• tạo nơi để engineer kiểm tra lỗi
• cho phép replay sau khi sửa lỗi

DLQ giúp hệ thống:

• resilient hơn
• dễ debug hơn
• ít bị downtime do message lỗi

Hãy nghĩ DLQ như “khu cách ly” dành cho những job gây lỗi, đợi được xem xét và xử lý lại.

VI. Observability and Security (Quan sát hệ thống & bảo mật)

Distributed Tracing

Distributed tracing theo dõi một request khi nó đi qua nhiều service trong một kiến trúc microservices.

Mỗi service thêm:

• trace ID (để nhận diện request)
• span (thời gian thực thi của từng service hoặc operation)

Nhờ vậy bạn có thể dựng lại hành trình đầy đủ của request, từ API → service A → service B → message queue → DB → cache…

Không có tracing → bạn chỉ thấy lỗi xuất hiện ở từng service riêng lẻ.
Có tracing → bạn thấy toàn bộ luồng xử lý và biết bottleneck, latency, hoặc failure xảy ra ở đâu.

Đây là vũ khí không thể thiếu khi debug hệ thống phức tạp.

SLA vs SLO vs SLI

• SLA (Service Level Agreement)
  Cam kết đối ngoại với khách hàng, ví dụ:
  “Uptime 99.9% mỗi tháng.”
• SLO (Service Level Objective)
  Mục tiêu nội bộ mà đội kỹ thuật đặt ra, thường khắt khe hơn SLA.
• SLI (Service Level Indicator)
  Chỉ số thực tế đo được:
  • uptime thực
  • error rate
  • request success rate
  • latency p95/p99

Nói đơn giản:
SLA = hợp đồng,
SLO = mục tiêu,
SLI = bảng điểm thực tế.

Trong phỏng vấn, việc dùng đúng ba khái niệm này thể hiện bạn hiểu tư duy reliability chuyên nghiệp.

OAuth 2.0 và OIDC

• OAuth 2.0: framework cho ủy quyền (authorization).
  Cho phép ứng dụng A truy cập tài nguyên của user ở ứng dụng B mà không cần password.
  (Ví dụ: cho phép app photo truy cập Google Drive của bạn.)
• OIDC (OpenID Connect): lớp authentication xây trên OAuth 2.0.
  Giúp xác minh user là ai và cung cấp thông tin danh tính qua ID Token.

Đây là nền tảng của các flow:

• “Login with Google”
• “Login with Facebook”
• “Login with Apple”

Cốt lõi: Authorization Server phát hành token mà client và API có thể tin tưởng.

TLS/SSL Handshake

TLS/SSL đảm bảo bảo mật giao tiếp giữa client và server bằng cách mã hóa dữ liệu khi truyền.

Quy trình handshake gồm:

1. client & server thống nhất thuật toán mã hóa
2. trao đổi khóa công khai/khóa phiên
3. xác thực certificate (CA chứng thực)

Sau khi handshake hoàn tất:

• toàn bộ dữ liệu truyền đi được mã hóa
• chống nghe lén
• chống chèn sửa dữ liệu

Đây chính là lý do bạn thấy biểu tượng ổ khóa trên trình duyệt.

Không có TLS → bất kỳ ai trong mạng đều có thể đọc hoặc sửa thông tin nhạy cảm.

Zero Trust Security

Zero Trust là mô hình bảo mật dựa trên nguyên tắc:

“Không tin ai cả – luôn xác minh.”
(Never trust. Always verify.)

Nó giả định rằng mối đe dọa có thể đến từ cả bên ngoài lẫn bên trong hệ thống.

Trong Zero Trust:

• mọi request đều phải authenticate + authorize + encrypt
• dù request đến từ nội bộ VPC, cluster, hay LAN
• quyền truy cập dựa vào identity, device state, và context (không dựa vào firewall zone)

Zero Trust ngày càng trở thành mặc định cho kiến trúc hiện đại, nhất là:

• hệ thống phân tán
• hybrid cloud
• remote work
• microservices

Không còn “mạng nội bộ là an toàn”; mọi yêu cầu đều phải chứng minh danh tính.

Key Takeaways (Những điểm kết luận quan trọng)

• System design là bài toán của những đánh đổi (trade-off).
  Bạn luôn phải cân bằng giữa:
  • consistency ↔ availability
  • latency ↔ throughput
  • simplicity ↔ flexibility
    Không có lựa chọn hoàn hảo, chỉ có lựa chọn phù hợp với nhu cầu.
• Scaling không chỉ là “thêm server.”
  Bạn phải suy nghĩ về:
  • load balancer
  • sharding
  • replication
  • bottlenecks (điểm nghẽn)
    Scaling hiệu quả là thiết kế lại kiến trúc, không chỉ mở rộng phần cứng.
• Reliability pattern tồn tại vì lỗi là điều hiển nhiên trong hệ thống phân tán.
  Rate limiting, circuit breaker, retry + backoff, bulkhead…
  → tất cả nhằm ngăn lỗi cục bộ lan thành sự cố toàn hệ thống.
• Caching, queues, pub-sub là công cụ mạnh để tăng performance và decouple,
  nhưng chúng cũng tạo ra các thách thức mới như:
  • inconsistency
  • ordering
  • stale data
  • message duplication
• Observability & Security là trụ cột của hệ thống hiện đại.
  Distributed tracing, SLIs/SLOs, OAuth/OIDC, TLS, Zero Trust…
  → giúp hệ thống không chỉ nhanh, mà còn an toàn, dễ theo dõi, và dễ debug.

Reference: https://designgurus.substack.com/p/50-system-design-concepts-for-beginners