System Design cho BA/PM trong Tech

Hiểu kiến trúc – Nói chuyện cùng Engineer – Quyết định tốt hơn

Có bao giờ bạn tự hỏi điều gì thực sự xảy ra khi chúng ta truy cập vào một trang web hay một ứng dụng không?

Chúng ta thường mở trình duyệt, gõ một đường link, nhấn Enter và mọi thứ hiện ra gần như ngay lập tức. Màn hình load rất nhanh, dữ liệu được hiển thị mượt mà, đôi khi còn có thông báo real-time xuất hiện đúng thời điểm. Tất cả diễn ra trơn tru đến mức chúng ta hiếm khi đặt câu hỏi: phía sau cú click đó là gì?

Thực tế, trong vài giây ngắn ngủi đó, hệ thống đã thực hiện hàng loạt bước phức tạp: từ việc tìm đúng server đang giữ dữ liệu, phân phối request tới nơi phù hợp, kiểm tra quyền truy cập, xử lý logic nghiệp vụ, truy xuất dữ liệu, cho tới việc trả kết quả về cho người dùng, tất cả đều phải diễn ra nhanh, chính xác và ổn định.

Vấn đề là, rất nhiều thuật ngữ chúng ta thường nghe như load balancer, cache, API, database, queue, scaling… lại xuất hiện rời rạc, thiếu bối cảnh tổng thể. Điều này khiến không ít bạn làm trong lĩnh vực Tech rơi vào cảm giác: “Mình nghe quen đấy, nhưng nếu hỏi sâu thì lại không biết bắt đầu từ đâu.”

Và đó cũng là lý do mình muốn viết bài này. Không phải để biến bạn thành một Engineer, mà để giúp bạn nhìn thấy bức tranh toàn cảnh của hệ thống — hiểu mỗi khái niệm đang đứng ở đâu, đóng vai trò gì, và vì sao nó lại quan trọng trong các quyết định về sản phẩm, nghiệp vụ hay roadmap kỹ thuật.

Trước khi đi vào từng khái niệm, hãy cùng nhau trả lời câu hỏi nền tảng nhất:

Khi một người dùng truy cập vào website hoặc ứng dụng của bạn, hệ thống thực sự đang làm gì?

Từ câu hỏi đó, chúng ta sẽ lần lượt mở ra toàn bộ thế giới của System Design — theo cách dễ hiểu nhất cho BA/PM trong lĩnh vực Tech.

---

0. Bức tranh lớn của các hệ thống hiện nay

Trước khi đi vào từng thuật ngữ, mình muốn bạn hình dung một điều đơn giản:

Một hệ thống hiện đại không phải là một khối duy nhất,

mà là nhiều lớp phối hợp với nhau để xử lý dữ liệu.

Dù là website, mobile app hay SaaS platform, phần lớn đều xoay quanh cùng một cấu trúc nền tảng:

User → Network → Application → Data → Async Processing

Từ bức tranh lớn này, chúng ta sẽ lần lượt bóc tách từng lớp, tương ứng với khoảng 20 khái niệm system design cốt lõi mà bạn thường nghe thấy trong Tech.

---

1. Scaling

Vertical Scaling

Vertical scaling đơn giản là nâng cấp một server duy nhất: thêm CPU, thêm RAM, thêm disk.

Ở giai đoạn đầu của phát triển product, đây thường là lựa chọn hợp lý vì:

• Nhanh

• Ít thay đổi kiến trúc

• Chi phí quản lý thấp

Nhưng với BA/PM, điều cần nhận ra là: vertical scaling luôn có giới hạn. Đến một lúc nào đó, bạn không thể mua máy mạnh hơn được nữa.

Horizontal Scaling

Horizontal scaling là thêm nhiều server giống nhau để cùng xử lý request.

Đây là cách các hệ thống lớn vận hành, vì:

• Có thể mở rộng gần như vô hạn

• Tăng khả năng chịu lỗi

• Phù hợp khi user tăng trưởng nhanh

Với BA/PM, câu hỏi không phải là “có scale ngang hay không”, mà là “sản phẩm của mình đã sẵn sàng cho scale ngang chưa?”

---

2. Load Balancer

Khi có nhiều server, hệ thống cần một cơ chế để:

• Phân phối request đều

• Tránh quá tải

• Phát hiện server lỗi

Load balancer đảm nhận vai trò đó.

Từ góc nhìn BA/PM:

• Load balancer giúp xóa single point of failure

• Là nền tảng cho uptime, SLA và trải nghiệm người dùng

Nếu không có load balancer, mọi nỗ lực scale phía sau đều trở nên mong manh.

---

3. CDN & Caching

Content Delivery Network (CDN)

CDN giải quyết một vấn đề rất con người:

User ở xa server thì sẽ thấy chậm.

Thay vì bắt mọi request quay về một nơi, CDN đưa nội dung tĩnh (image, JS, CSS) đến gần người dùng hơn.

Với BA/PM, CDN thường liên quan trực tiếp tới:

• Trải nghiệm người dùng

• Chi phí hạ tầng

• Mức độ hài lòng của khách hàng ở các quốc gia khác nhau

Caching

Caching là câu trả lời cho câu hỏi:

“Tại sao phải lấy lại dữ liệu giống nhau nhiều lần?”

Cache giúp:

• Giảm tải database

• Giảm latency

• Tăng khả năng chịu tải

Điều quan trọng với BA/PM không phải là cache bằng công nghệ gì, mà là hiểu trade-off giữa dữ liệu real-time và hiệu năng.

---

4. Network nền tảng – IP, TCP/IP và DNS

IP Address

Mỗi thiết bị trên mạng đều có một địa chỉ định danh. Không có IP, các hệ thống không thể nói chuyện với nhau. Ví dụ: Server: 203.113.xxx.xxx. Client sẽ gửi request tới IP này.

TCP/IP

TCP/IP là bộ quy tắc giúp dữ liệu:

• Được chia thành packet

• Gửi đi

• Ghép lại đúng thứ tự

• Gửi lại nếu bị mất

Đây là lý do các giao thức cấp cao hơn (HTTP, WebSocket) có thể hoạt động ổn định.

DNS

DNS giúp con người không phải nhớ IP. Từ góc nhìn BA/PM, DNS thường liên quan đến:

• Routing đa vùng

• Failover

• Thời gian phản hồi ban đầu của hệ thống

Ví dụ: substack.com → 104.xxx.xxx.xxx

---

5. HTTP & các mô hình API

HTTP

HTTP là giao thức mà hầu hết sản phẩm Tech sử dụng hàng ngày.

Client gửi request → server trả response, gồm:

• Header (metadata)

• Body (data)

REST

REST là chuẩn API phổ biến nhất:

• Stateless

• Dễ hiểu

• Phù hợp với CRUD

BA/PM thường gặp REST trong:

• API tài liệu

• Integration

• Third-party services

GraphQL

GraphQL cho phép client chỉ lấy đúng dữ liệu cần.

Từ góc nhìn sản phẩm:

• Giảm over-fetching

• Tối ưu cho mobile

• Tăng độ linh hoạt frontend

Nhưng đi kèm là độ phức tạp vận hành cao hơn.

gRPC

gRPC thường xuất hiện trong hệ thống backend phức tạp:

• Microservices

• Giao tiếp server-to-server

• Yêu cầu hiệu năng cao

BA/PM không cần dùng gRPC, nhưng nên hiểu vì sao team chọn nó.

WebSocket

WebSocket giải quyết bài toán real-time:

• Chat

• Notification

• Live update

Thay vì client hỏi liên tục, server push dữ liệu ngược lại.

---

6. Data Layer – SQL, NoSQL và ACID

SQL & ACID

SQL database đảm bảo:

• Giao dịch an toàn

• Dữ liệu nhất quán

• Phù hợp với payment, order, tài chính

ACID là lý do SQL chậm hơn nhưng đáng tin hơn.

• Atomicity: all or nothing

• Consistency: dữ liệu hợp lệ

• Isolation: transaction không ảnh hưởng nhau

• Durability: dữ liệu không mất khi crash

NoSQL

NoSQL hy sinh một phần consistency để:

• Scale tốt hơn

• Linh hoạt hơn

Phổ biến

• Key-Value (Redis)

• Document (MongoDB)

• Graph (Neo4j)

BA/PM cần hiểu rằng:

Không phải mọi dữ liệu đều cần ACID.

---

7. Replication, Sharding & CAP

Replication

• Scale read

• Tăng độ sẵn sàng

Sharding

• Chia dữ liệu để scale write, chia database theo chiều ngang

• Mỗi shard chứa một phần data

• Phức tạp, rủi ro cao

CAP Theorem

Khi hệ thống phân tán:

• Không thể có đồng thời Consistency, Availability và Partition tolerance

Đây là tư duy đánh đổi cốt lõi trong system design.

---

8. Message Queue

Message queue giúp:

• Xử lý bất đồng bộ

• Tách các module

• Chống overload

BA/PM thường gặp queue trong:

• Email

• Analytics

• Event processing

---

Kết luận

System Design không phải là checklist công nghệ.

Nó là:

• Cách hệ thống phản ứng khi có vấn đề

• Cách sản phẩm mở rộng khi thành công

• Cách đội ngũ đưa ra quyết định dài hạn

Hiểu system design là:

Hiểu hệ thống đủ sâu để đưa ra các quyết định phù hợp.

Trong khuôn khổ bài viết này, không thể giải thích chi tiết và đầy đủ các khái niệm, vì thế các bạn có thể dựa trên các khái niệm này để tiếp tục tìm hiểu thêm. Hy vọng bài viết sẽ mang lại cho bạn góc nhìn về System Design.

Trong các bài viết sắp tới, mình cũng sẽ chia sẻ thêm về System Architecture và các mô hình phổ biến trong các hệ thống hiện nay.