TL;DR

System design không phải môn học lý thuyết thuần túy. Đây là tập hợp các quyết định kiến trúc quyết định liệu hệ thống của bạn có thể phục vụ 100 user hay 500,000 user mỗi ngày. Bài viết này đi qua 5 khái niệm nền tảng đầu tiên: Scalability, Load Balancing, Caching, Databases và Microservices - với giải thích thực tế và ví dụ cụ thể từ production.

via @e_opore trên X

Scalability, Load Balancing và Caching architecture diagram

1. Scalability - Thiết kế để tăng quy mô

Scalability là khả năng hệ thống xử lý tải tăng dần mà không làm giảm hiệu năng theo tỷ lệ tương đương. Có hai hướng chính:

  • Vertical scaling (scale-up): Thêm CPU, RAM vào máy chủ hiện có. Đơn giản để triển khai nhưng bị giới hạn bởi phần cứng và tạo ra single point of failure.
  • Horizontal scaling (scale-out): Thêm máy chủ mới vào cluster. Phức tạp hơn về mặt kiến trúc nhưng không có giới hạn lý thuyết và chịu lỗi tốt hơn.

Một ví dụ thực tế: một developer đã phải mất 4 tháng để migrate database lên kiến trúc sharding sau khi hệ thống tăng từ 100 lên 500,000 daily users. Quyết định kiến trúc sớm - như stateless services và horizontal-first design - có thể tiết kiệm những cuộc migration đau đớn đó.

Nguyên tắc quan trọng: thiết kế cho stateless application services. Khi service không giữ state cục bộ, bạn có thể thêm hoặc xóa instances bất kỳ lúc nào mà không ảnh hưởng đến user session.

2. Load Balancing - Phân phối traffic thông minh

Load balancer đứng trước nhiều server và phân phối incoming requests để không server nào bị overload. Không có load balancing, một server duy nhất sẽ trở thành bottleneck - và khi nó crash, toàn bộ hệ thống sập.

Các thuật toán load balancing phổ biến:

  • Round Robin: Phân phối request lần lượt theo vòng tròn. Đơn giản nhưng không tính đến độ nặng nhẹ của từng request.
  • Least Connections: Gửi request đến server đang xử lý ít connections nhất. Hiệu quả hơn khi requests có thời gian xử lý không đồng đều.
  • IP Hash: Request từ cùng một IP luôn đến cùng một server. Hữu ích khi cần session persistence.

Trong hệ thống hiện đại năm 2026, load balancing không chỉ là round-robin đơn thuần. Intelligent routing dựa trên latency, geographic location và service health giúp tối ưu cả performance lẫn availability. Load balancer cũng thường kết hợp với API gateway để xử lý authentication và rate limiting tại một điểm duy nhất.

via System Design Handbook

3. Caching - Tầng tăng tốc và kiểm soát chi phí

Caching là một trong những kỹ thuật bị hiểu nhầm nhiều nhất trong system design. Người ta thường nghĩ caching chỉ để tăng tốc, nhưng trong hệ thống production, caching còn là công cụ kiểm soát chi phí infrastructure quan trọng.

Cache hoạt động bằng cách lưu trữ kết quả của các operations tốn kém (database query, API call, heavy computation) ở nơi truy cập nhanh hơn. Khi request giống nhau đến lần sau, hệ thống trả về từ cache thay vì thực hiện lại operation đó.

Các tầng cache trong hệ thống hiện đại:

  • Browser cache: File tĩnh (CSS, JS, images) lưu tại client
  • CDN edge cache: Content phân phối tại các điểm gần user nhất địa lý
  • In-memory cache (Redis, Memcached): Data thường xuyên truy cập lưu trong RAM, latency microseconds
  • Application-level cache: Cache tại tầng logic của ứng dụng

Ba câu hỏi cần trả lời khi thiết kế caching layer: Data nào cần cache? Cache tồn tại bao lâu? Invalidation được xử lý như thế nào? Cache invalidation - biết khi nào xóa cache cũ - là phần khó nhất và là nguồn gốc của nhiều bugs tinh vi trong production.

4. Databases - SQL, NoSQL, Replication và Sharding

Quyết định chọn database là một trong những quyết định khó đảo ngược nhất trong system design. Sai ở đây có thể dẫn đến months-long migration như đã đề cập ở phần Scalability.

Hai trường phái chính:

  • SQL (Relational): PostgreSQL, MySQL - phù hợp cho transactional data, complex joins, strong consistency (ACID). Schema cứng nhưng đảm bảo data integrity.
  • NoSQL (Document, Key-Value, Graph): MongoDB, DynamoDB, Redis - phù hợp cho flexible schema, massive write throughput, horizontal scaling. Trade-off là giảm consistency guarantees.

Khi data tăng vượt ngưỡng một máy:

  • Replication: Giữ nhiều bản copy data trên các server khác nhau. Primary nhận writes, replicas phục vụ reads. Tăng availability và read performance, nhưng phát sinh vấn đề consistency giữa primary và replica.
  • Sharding: Chia data ngang (horizontal partitioning) ra nhiều database servers theo một shard key (user ID, region, time range). Tăng write throughput nhưng phức tạp về routing và có nguy cơ hotspot nếu chọn shard key sai.

Nguyên tắc thực tế: chọn database dựa trên access patterns và consistency requirements của ứng dụng, không phải dựa trên popularity. via Grokking System Design

5. Microservices - Chia nhỏ để scale độc lập

Microservices là kiến trúc chia application thành các services nhỏ, độc lập, mỗi service có thể được develop, deploy và scale riêng biệt. Trái ngược với monolith - nơi mọi thứ nằm chung một codebase lớn.

Ưu điểm của microservices:

  • Independent scaling: Service xử lý payment có thể scale riêng mà không ảnh hưởng service quản lý user profile
  • Team autonomy: Các team có thể làm việc độc lập, deploy theo tốc độ riêng
  • Technology flexibility: Mỗi service có thể dùng ngôn ngữ/framework phù hợp nhất
  • Fault isolation: Một service crash không kéo theo toàn bộ hệ thống

Nhưng microservices không phải free lunch. Các vấn đề phát sinh:

  • Service discovery: làm sao services tìm thấy nhau? (Consul, etcd, Kubernetes DNS)
  • Network latency giữa các services
  • Distributed transactions khó hơn nhiều so với monolith
  • Observability phức tạp hơn: phải track request qua nhiều services

Quyết định monolith vs microservices không phải trắng đen. Nhiều team thành công bắt đầu với monolith well-structured, chỉ tách ra microservices khi có nhu cầu scaling cụ thể - không phải vì microservices nghe "modern" hơn.

Kết - P1

Năm khái niệm nền tảng này - Scalability, Load Balancing, Caching, Databases, Microservices - là những building blocks mà mọi hệ thống production đều phải đối mặt. Không nhất thiết phải implement tất cả từ đầu, nhưng hiểu rõ trade-offs giúp bạn đưa ra quyết định kiến trúc đúng thời điểm.

Phần 2 sẽ đi vào 5 khái niệm còn lại: Message Queues, API Gateway, Fault Tolerance, Distributed Systems và Monitoring & Logging - những thứ quyết định hệ thống có trụ được khi xảy ra failure hay không.