Tổng hợp và diễn giải chi tiết 16 khái niệm nền tảng của system design — từ DNS, Load Balancer, API Gateway đến Sharding, NoSQL và Distributed Coordination — giúp CTO và người ra quyết định hiểu đúng kiến trúc hệ thống, đánh giá đề xuất kỹ thuật và trao đổi hiệu quả với team engineering.
Phỏng vấn ứng viên engineering, đánh giá đề xuất kiến trúc từ team kỹ thuật, hay quyết định đầu tư hạ tầng cho giai đoạn scale tiếp theo — trong mọi tình huống đó, người ra quyết định không cần tự code, nhưng cần hiểu đúng bản chất của các thành phần đang được nói tới. Hiểu sai một khái niệm nền tảng dễ dẫn tới quyết định sai: phê duyệt một kiến trúc quá phức tạp so với quy mô thực tế, hoặc đánh giá thấp rủi ro của một thiết kế tưởng chừng đơn giản.
Sơ đồ trên minh họa “System Design Master Template” — bản đồ tổng quan các thành phần thường xuất hiện trong một hệ thống phần mềm hiện đại: từ Load Balancer, API Gateway, CDN ở lớp ngoài, đến Metadata Server, Cache, Sharding, Message Queue, Search Index và Data Warehouse ở lớp trong. 16 khái niệm dưới đây sẽ giải thích từng mảnh trong bức tranh đó, sắp xếp theo đúng thứ tự một request thực tế đi qua hệ thống: từ lúc người dùng gõ URL đến khi dữ liệu được xử lý và trả về.
DNS là “cuốn danh bạ” của Internet — nó tồn tại vì con người nhớ tên (nexlifysolutions.io) tốt hơn nhớ số (192.0.2.1), nhưng máy chủ chỉ định tuyến được bằng địa chỉ IP.
Quá trình phân giải diễn ra theo nhiều bước, không phải một lần tra cứu đơn giản:
nexlifysolutions.io, nhưng biết server nào quản lý domain .io..com), server này trả về địa chỉ của authoritative name server — nơi lưu thông tin chính xác của domain.nexlifysolutions.io.Điểm cần lưu ý khi đánh giá hạ tầng: DNS caching (giảm số lần phải đi qua toàn bộ chuỗi resolver, ảnh hưởng trực tiếp tới thời gian tải trang lần đầu) và DNS load balancing — dùng DNS để trả về nhiều IP khác nhau cho cùng một domain, giúp phân tải ngay từ bước phân giải tên, trước khi request chạm tới hạ tầng thực sự.
Load balancer là lớp đứng giữa client và một nhóm server backend, quyết định request nào đi tới server nào. Mục tiêu: không để một server nào quá tải trong khi server khác rảnh rỗi, đồng thời phát hiện và loại server đang lỗi ra khỏi vòng xoay (health check).
Ba thuật toán phổ biến, mỗi thuật toán phù hợp một tình huống khác nhau:
Load balancer còn có hai loại theo layer mạng: Layer 4 (định tuyến theo IP/port, nhanh nhưng không hiểu nội dung HTTP) và Layer 7 (hiểu được HTTP header, path, cookie — cho phép định tuyến thông minh hơn, ví dụ route /api/v2 tới cluster mới trong lúc migrate).
Khi hệ thống có hàng chục microservices, để client gọi trực tiếp từng service là một cơn ác mộng bảo trì — client phải biết địa chỉ của mọi service, xử lý auth riêng cho từng nơi, và mỗi lần một service đổi API là client vỡ. API Gateway giải quyết vấn đề này bằng cách trở thành điểm vào duy nhất.
Các chức năng chính:
Điểm cần phân biệt rõ: API Gateway không thay thế Load Balancer. Load balancer phân tải giữa các instance của cùng một service; API Gateway định tuyến giữa các service khác nhau và xử lý logic ở tầng ứng dụng (application layer). Nhầm lẫn hai vai trò này khi lên kế hoạch hạ tầng dễ dẫn tới thiết kế thiếu một tầng quan trọng.
CDN giải quyết một vấn đề vật lý: tốc độ ánh sáng là có hạn, và khoảng cách địa lý giữa server gốc và người dùng tạo ra độ trễ không thể tối ưu bằng code. Giải pháp là đặt bản sao nội dung ở nhiều nơi trên thế giới, gần người dùng hơn.
Cơ chế hoạt động:
Cache-Control, ETag, hoặc TTL cấu hình sẵn).Trong thực tế, CDN không chỉ dùng cho ảnh/video — nhiều hệ thống hiện đại còn cache API response ở edge (edge caching cho GET request ít thay đổi), hoặc dùng edge compute (Cloudflare Workers, Lambda@Edge) để xử lý logic ngay tại edge, giảm round-trip về origin.
Hai khái niệm này hay bị nhầm lẫn vì cấu trúc tương tự (một server đứng giữa), nhưng phục vụ hai mục đích ngược nhau:
Một cách nhớ nhanh: forward proxy bảo vệ và kiểm soát client; reverse proxy bảo vệ và kiểm soát server.
Cache là lớp lưu trữ tốc độ cao (thường là RAM) nằm giữa ứng dụng và nguồn dữ liệu gốc — vốn chậm hơn nhiều (disk, network call, database query phức tạp). Nguyên tắc chung: kiểm tra cache trước (cache hit → trả về ngay), nếu không có (cache miss) mới đi lấy từ nguồn gốc, lưu lại vào cache, rồi trả về.
Trong một hệ thống thực tế, cache tồn tại ở nhiều tầng cùng lúc, không chỉ một chỗ:
Câu hỏi quan trọng khi thiết kế cache không phải “có nên cache không” mà là cache invalidation — khi nào dữ liệu cache trở nên cũ, và làm sao đảm bảo người dùng không thấy dữ liệu sai lệch. Ba chiến lược phổ biến: TTL (hết hạn sau X giây), write-through (cập nhật cache ngay khi ghi dữ liệu gốc), và cache-aside (ứng dụng tự quản lý việc đọc/ghi cache, phổ biến nhất trong thực tế vì đơn giản và linh hoạt).
Khi một bảng dữ liệu lớn đến mức một server không chứa hoặc xử lý nổi, có hai cách chia nhỏ:
user_id). Mỗi shard chứa một tập con user, và khi cần đọc/viết dữ liệu của một user, hệ thống định tuyến chính xác tới shard chứa họ. Đây là cách chính để scale ghi (write throughput) khi một server không đủ sức chứa toàn bộ dữ liệu.Chọn sai shard key là lỗi phổ biến nhất khi sharding: nếu chọn key khiến dữ liệu phân bố không đều (ví dụ shard theo ngày tạo tài khoản, nhưng có một ngày spike traffic bất thường), một shard sẽ trở thành hotspot — quá tải trong khi các shard khác rảnh. Ngoài ra, sharding làm cho các thao tác cross-shard (join dữ liệu giữa hai user ở hai shard khác nhau, hoặc transaction xuyên shard) trở nên phức tạp và tốn chi phí đáng kể — đây là lý do sharding thường là lựa chọn cuối cùng, sau khi đã tận dụng hết read replica và cache.
Replication là kỹ thuật duy trì nhiều bản sao của cùng một database trên các server khác nhau — không phải để chia dữ liệu (như sharding) mà để nhân bản toàn bộ.
Mô hình phổ biến nhất: một primary (master) nhận toàn bộ write, và một hoặc nhiều replica (slave) đồng bộ dữ liệu từ primary (qua binlog replication hoặc streaming replication, tùy hệ quản trị CSDL). Ứng dụng route write tới primary, và route read tới replica.
Lợi ích cụ thể:
Điểm quan trọng khi đánh giá SLA và uptime của hệ thống: replication lag — độ trễ giữa lúc primary ghi dữ liệu và lúc replica cập nhật xong. Nếu ứng dụng đọc ngay từ replica sau khi vừa viết vào primary, người dùng có thể thấy dữ liệu cũ (tình huống “tôi vừa đổi tên, tại sao vẫn thấy tên cũ?”). Đây là câu hỏi nên đặt ra khi team kỹ thuật đề xuất thêm replica: “Độ trễ đồng bộ tối đa là bao lâu, và nghiệp vụ nào không chấp nhận được độ trễ đó?“
Khi hai service cần trao đổi thông tin nhưng không muốn phụ thuộc trực tiếp vào nhau (nếu service B đang down, service A không nên vì thế mà cũng lỗi), giải pháp là đưa một message broker vào giữa. Service A đẩy message vào queue/topic, service B đọc và xử lý khi rảnh — hai bên hoàn toàn tách rời (decoupled) về thời gian và về vòng đời triển khai.
Hai mô hình chính:
Kafka còn có thêm khả năng lưu trữ log bền vững (message không mất đi sau khi được đọc, có thể replay), khiến nó phù hợp cho cả event sourcing và xử lý dữ liệu real-time ở quy mô lớn — đây là lý do Kafka phổ biến hơn RabbitMQ trong các hệ thống data-intensive.
Microservices là kiến trúc chia một ứng dụng lớn thành nhiều service nhỏ, độc lập, mỗi service sở hữu một domain nghiệp vụ cụ thể — đối lập với monolith, nơi toàn bộ logic nằm trong một codebase, một quá trình deploy.
Đặc điểm cốt lõi:
Đánh đổi cần cân nhắc khi phê duyệt kiến trúc microservices: nó giải quyết được vấn đề scale tổ chức (nhiều team làm việc độc lập) và scale kỹ thuật (scale riêng từng phần), nhưng đổi lại là độ phức tạp vận hành tăng mạnh — cần service discovery, distributed tracing, quản lý version API giữa các service, và xử lý network failure (thứ không tồn tại trong monolith vì mọi thứ chạy trong cùng một process). Với đội ngũ nhỏ hoặc sản phẩm giai đoạn đầu, microservices thường là chi phí sớm hơn là lợi ích — nên là quyết định cân nhắc kỹ, không phải xu hướng cần chạy theo.
NoSQL ra đời để giải quyết những bài toán mà database quan hệ (schema cố định, ACID transaction nặng) không tối ưu: dữ liệu phi cấu trúc, khối lượng lớn, cần scale ngang dễ dàng. Bốn nhóm chính, mỗi nhóm phù hợp một dạng bài toán khác nhau:
Điểm quan trọng khi trao đổi với team kỹ thuật về lựa chọn database: đừng chấp nhận lý do “NoSQL nhanh hơn SQL” một cách chung — hãy yêu cầu làm rõ NoSQL đánh đổi consistency mạnh và khả năng join phức tạp để lấy khả năng scale ngang và schema linh hoạt. Lựa chọn đúng phụ thuộc vào shape dữ liệu và pattern truy vấn thực tế, không phải xu hướng công nghệ.
Không có index, một câu query WHERE email = 'x@y.com' buộc database phải quét từng dòng trong bảng (full table scan) — chấp nhận được với 1,000 dòng, nhưng thành thảm họa với 100 triệu dòng. Index là cấu trúc dữ liệu phụ, giống mục lục sách, cho phép DBMS nhảy thẳng tới vị trí dữ liệu cần tìm.
Loại phổ biến nhất là B-tree index — tổ chức dữ liệu theo cây phân cấp, hỗ trợ tốt cho tìm kiếm chính xác, range query (WHERE age BETWEEN 20 AND 30), và sắp xếp. Ngoài ra còn có hash index (nhanh cho tìm kiếm chính xác nhưng không hỗ trợ range query) và bitmap index (hiệu quả cho cột có ít giá trị khác nhau, ví dụ trạng thái đơn hàng).
Đánh đổi luôn phải nhắc tới khi nói về index:
Nguyên tắc thực tế: chỉ đánh index trên cột thường xuất hiện trong WHERE, JOIN, hoặc ORDER BY — đánh index tràn lan “cho chắc” là một trong những nguyên nhân phổ biến khiến hệ thống ghi dữ liệu chậm dần theo thời gian.
Khi lượng file (ảnh, video, log, backup) lớn đến mức một server không chứa nổi, hoặc cần truy cập từ nhiều nơi đồng thời, distributed file system cho phép lưu trữ file trải trên nhiều server nhưng vẫn truy cập được như một file system thống nhất — ứng dụng không cần biết file thực sự nằm ở node nào.
Kiến trúc phổ biến gồm hai loại node: metadata server (lưu thông tin về file nằm ở đâu, ai sở hữu, quyền truy cập — tương ứng với “Metadata Server” trong sơ đồ template) và block/data server (lưu nội dung file thực tế, thường được chia nhỏ thành block và replicate ra nhiều node để chống mất dữ liệu). Ví dụ điển hình: HDFS (Hadoop Distributed File System), Google File System (GFS) — nền tảng cho toàn bộ hệ sinh thái xử lý dữ liệu lớn hiện nay.
Notification system chịu trách nhiệm gửi thông báo tới người dùng — email, push notification, SMS — thường ở quy mô lớn (hàng triệu người dùng cùng lúc trong một số trường hợp, như thông báo khuyến mãi).
Thiết kế đúng đắn gần như luôn đi qua message queue: service nghiệp vụ (ví dụ service đơn hàng) không tự gửi email trực tiếp, mà đẩy một message vào queue (“đơn hàng #123 đã xác nhận”), và một notification service riêng đọc queue, xử lý logic gửi (chọn kênh, template, retry khi thất bại). Cách này giúp:
Tìm kiếm theo LIKE '%keyword%' trong SQL không scale — vừa chậm, vừa không hiểu ngữ nghĩa (không phân biệt được “chạy” và “chạy bộ” nên liên quan tới nhau). Full-text search giải quyết bài toán này bằng inverted index — cấu trúc dữ liệu ánh xạ ngược từ từ khóa tới danh sách document chứa từ đó, kèm thông tin vị trí và độ liên quan (relevance score).
Ví dụ: khi index câu “Nexlify xây dựng hệ thống scale” và “Nexlify tư vấn kỹ thuật”, inverted index sẽ lưu: Nexlify → [doc1, doc2], xây dựng → [doc1], tư vấn → [doc2]. Khi user tìm “Nexlify”, hệ thống tra ngay ra [doc1, doc2] mà không cần quét toàn bộ nội dung. Elasticsearch (dựa trên Apache Lucene) là công cụ phổ biến nhất cho bài toán này, thường được đặt cạnh database chính (không thay thế database, mà đồng bộ dữ liệu qua để phục vụ riêng nhu cầu tìm kiếm).
Trong một hệ thống có hàng chục, hàng trăm node chạy song song, có những vấn đề mà từng node riêng lẻ không tự giải quyết được: ai là leader trong một cụm service? Config nào đang là bản mới nhất và mọi node cần đồng bộ theo? Node nào đang sống, node nào đã chết? Đây là vai trò của distributed coordination service.
Các chức năng chính:
Ví dụ điển hình: Apache ZooKeeper (dùng trong Kafka, HBase), etcd (dùng trong Kubernetes để lưu toàn bộ state của cluster), Consul (service discovery và config trong kiến trúc microservices).
16 khái niệm trên gần như là bộ “từ vựng nền” để hiểu bất kỳ kiến trúc hệ thống hiện đại — từ một nền tảng thương mại điện tử, ứng dụng fintech, đến hệ thống nội bộ quy mô doanh nghiệp. Nhưng nhớ tên và định nghĩa chỉ là điều kiện cần; giá trị thực sự đến từ khả năng đặt đúng câu hỏi khi đánh giá một đề xuất kỹ thuật — biết khi nào chọn sharding thay vì chỉ thêm read replica, khi nào cần message queue thay vì gọi API đồng bộ trực tiếp, khi nào một hệ thống cần strong consistency và khi nào eventual consistency là đủ.
Với vai trò CTO hoặc chủ doanh nghiệp, cách áp dụng hiệu quả nhất không phải là tự thiết kế hệ thống, mà là dùng các khái niệm này để đặt đúng câu hỏi cho team kỹ thuật: “Tại sao chọn kiến trúc này thay vì đơn giản hơn?”, “Nếu traffic tăng gấp 10 lần, thành phần nào sẽ vỡ trước?”, “Chúng ta đang đánh đổi gì để lấy khả năng scale đó?” Trả lời được — hoặc biết cách yêu cầu team trả lời — những câu hỏi đó chính là lúc kiến thức kỹ thuật chuyển thành khả năng ra quyết định đầu tư công nghệ đúng đắn.
Bài viết tổng hợp và diễn giải từ “16 System Design Concepts I Wish I Knew Before the Interview” của Arslan Ahmad trên Level Up Coding. Nếu bạn là CTO hoặc chủ doanh nghiệp đang cần đánh giá kiến trúc hoặc lên kế hoạch scale hệ thống, liên hệ với Nexlify để trao đổi.