- Thiết kế hệ thống chat real-time như thế nào?
- Thiết kế infinite scroll feed (như Facebook/Twitter)?
- Thiết kế form builder (drag & drop)?
- Caching strategies cho frontend app?
Có nhiều tầng caching cho frontend application, mỗi tầng phục vụ mục đích khác nhau. Tầng trình duyệt dùng HTTP headers như Cache-Control và ETag để cache tài nguyên tĩnh (JS, CSS, images), giúp giảm network requests khi user quay lại trang. Tầng ứng dụng…
- CAP Theorem là gì và tại sao nó quan trọng trong thiết kế hệ thống phân tán?
CAP Theorem phát biểu rằng một hệ thống phân tán chỉ có thể đảm bảo đồng thời tối đa 2 trong 3 thuộc tính: Consistency (tính nhất quán – mọi node trả về dữ liệu mới nhất), Availability (tính sẵn sàng – mọi request đều…
- ACID và BASE khác nhau như thế nào? Khi nào dùng mỗi mô hình?
ACID (Atomicity, Consistency, Isolation, Durability) là tập hợp thuộc tính đảm bảo transaction trong RDBMS luôn đáng tin cậy: toàn bộ transaction thành công hoặc rollback hoàn toàn, dữ liệu luôn hợp lệ, các transaction cô lập nhau, và dữ liệu đã commit không bao…
- Vertical Scaling và Horizontal Scaling là gì? Ưu nhược điểm của từng loại?
Vertical Scaling (scale up) là nâng cấp phần cứng của một máy chủ duy nhất: tăng CPU, RAM, SSD – đơn giản, không cần thay đổi code, nhưng bị giới hạn ở cấu hình phần cứng mạnh nhất và tạo ra single point of failure.…
- Load Balancing hoạt động như thế nào? Các thuật toán load balancing phổ biến là gì?
Load Balancer là thành phần đứng giữa client và các server, phân phối incoming requests để không có server nào bị quá tải, đồng thời tăng availability bằng cách redirect traffic khi có server bị lỗi. Các thuật toán phổ biến: Round Robin (luân phiên…
- CDN là gì và nó cải thiện hiệu năng hệ thống như thế nào?
CDN (Content Delivery Network) là mạng lưới các server phân tán địa lý, lưu trữ bản sao (cache) của static content (hình ảnh, JS, CSS, video) tại các edge nodes gần người dùng nhất. Khi user request một file, CDN route request đến edge node…
- Forward Proxy và Reverse Proxy khác nhau như thế nào? Mỗi loại dùng trong trường hợp nào?
Forward proxy đứng trước client và đại diện client gửi request ra ngoài — client biết có proxy, còn server bên ngoài không biết request thực sự xuất phát từ đâu. Dùng để vượt giới hạn địa lý, giấu IP client, lọc nội dung trong…
- Latency và Throughput là gì? Tại sao chúng thường có trade-off với nhau?
Latency là thời gian để hoàn thành một request đơn lẻ (đo bằng ms) – thấp là tốt, thể hiện độ nhanh nhạy của hệ thống. Throughput là số lượng requests/operations hệ thống xử lý được trong một đơn vị thời gian (requests/second, transactions/second) –…
- Các mô hình Consistency trong hệ thống phân tán là gì?
Các mô hình consistency phổ biến: - Strong Consistency (Linearizability): sau khi write thành công, mọi read sau đó đều thấy giá trị mới nhất – dễ lập trình nhất nhưng latency cao nhất vì cần coordination giữa các node. - Eventual Consistency: dữ liệu…
- Database Sharding là gì? Các chiến lược sharding phổ biến và khi nào nên dùng?
Sharding là kỹ thuật chia dữ liệu của một database thành nhiều phần nhỏ hơn (shards), mỗi shard nằm trên một database server riêng, cho phép scale ngang khi dữ liệu vượt quá capacity của một server. Các chiến lược: - Range-based sharding: chia theo…
- Read Replica là gì và nó giúp scale database như thế nào? Có những hạn chế nào?
Read Replica là bản sao của primary database, chỉ nhận read queries trong khi primary (master) nhận tất cả write queries – asynchronous replication đồng bộ dữ liệu từ primary sang replica. Lợi ích: giảm read load trên primary (80-90% workload thường là read), cho…
- Rate Limiting là gì? Các thuật toán rate limiting phổ biến và cách implement?
Rate Limiting là kỹ thuật kiểm soát tần suất request từ một client/IP/user để bảo vệ hệ thống khỏi abuse, DDoS, và đảm bảo fair usage. Các thuật toán: - Token Bucket – bucket chứa tokens, mỗi request tiêu 1 token, tokens được refill theo…
- Connection Pooling là gì và tại sao nó quan trọng cho database performance?
Connection Pooling duy trì sẵn một pool các kết nối đã được khởi tạo; application lấy connection từ pool và trả lại sau khi dùng xong — thay vì mở/đóng từng kết nối mới với overhead TCP handshake + authentication (20-100ms/lần). Lợi ích: giảm latency…
- CQRS Pattern là gì? Khi nào nên áp dụng và những thách thức gì khi implement?
CQRS (Command Query Responsibility Segregation) là pattern tách biệt hoàn toàn model đọc (Query) và model ghi (Command) – thay vì một model dùng cho cả CRUD. Command side xử lý mutations và thường dùng domain model phức tạp; Query side tối ưu cho read…
- Event Sourcing là gì? Lợi ích và hạn chế so với traditional state storage?
Event Sourcing là pattern lưu trữ mọi thay đổi trạng thái của application dưới dạng chuỗi immutable events thay vì chỉ lưu trạng thái hiện tại – giống như transaction log của bank hơn là số dư hiện tại. Ví dụ: thay vì lưu account.balance…
- Các pattern horizontal scaling cho stateful services là gì? Làm thế nào để handle session state?
Stateful services yêu cầu externalize state; các lựa chọn chính là Sticky Sessions, Externalized Store (Redis), và JWT — mỗi cách có trade-off riêng về complexity và failover. - Sticky Sessions: load balancer route cùng user về cùng server dựa trên cookie — đơn giản…
- Microservices và Monolith khác nhau như thế nào? Khi nào nên migrate sang Microservices?
Monolith là toàn bộ application được deploy như một unit duy nhất – đơn giản để develop, test, deploy ban đầu, không có network overhead giữa components. Microservices chia application thành nhiều services nhỏ, độc lập, mỗi service có database riêng và được deploy độc…
- API Gateway là gì? Vai trò và các tính năng chính của nó trong microservices architecture?
API Gateway là single entry point cho tất cả client requests đến microservices – hoạt động như reverse proxy với nhiều tính năng bổ sung. Vai trò: routing (forward request đến đúng service), authentication/authorization (centralized auth thay vì mỗi service tự verify), rate limiting, SSL…
- Service Mesh là gì và tại sao nó cần thiết trong kiến trúc microservices?
Service Mesh là tầng hạ tầng lo phần giao tiếp giữa các service trong kiến trúc microservice, thường hiện thực bằng sidecar proxy — mỗi pod của service có thêm một container proxy đi kèm. Nó cung cấp sẵn: mTLS để mã hoá liên lạc…
- Circuit Breaker Pattern là gì? Nó ngăn chặn cascading failures như thế nào?
Circuit Breaker là pattern bảo vệ hệ thống khỏi cascading failures khi một dependency bị lỗi – lấy cảm hứng từ cầu dao điện. Hoạt động qua 3 states: Closed (hoạt động bình thường, theo dõi failure rate), Open (sau khi failure rate vượt threshold,…
- Saga Pattern giải quyết vấn đề gì trong microservices? Choreography vs Orchestration?
Trong microservices, mỗi service có database riêng, nên không thể dùng distributed transactions (2PC) – quá phức tạp và tạo tight coupling. Saga Pattern giải quyết bằng cách chia distributed transaction thành chuỗi local transactions, mỗi bước publish event; nếu một bước fail, thực hiện…
- Event-Driven Architecture là gì? Lợi ích và các thách thức khi implement?
Event-Driven Architecture (EDA) là kiến trúc nơi các components giao tiếp với nhau qua events (notifications về điều gì đó đã xảy ra) thay vì direct API calls. Producer emit events mà không biết consumer là ai; consumer subscribe và xử lý events async –…
- Kafka và RabbitMQ khác nhau như thế nào? Khi nào dùng mỗi loại?
RabbitMQ là traditional message broker (queue-based): messages được push đến consumers, sau khi consumer acknowledge thì message bị xoá, hỗ trợ nhiều messaging patterns (pub/sub, point-to-point, routing với exchanges), tốt cho task queues và RPC. Kafka là distributed event log (log-based): messages được append vào…
- Serverless Architecture là gì? Ưu nhược điểm và khi nào phù hợp?
Serverless (FaaS – Function as a Service) là mô hình cloud computing nơi developer chỉ viết code (functions), không quản lý server infrastructure; provider tự động provision, scale, và bill theo actual invocations (pay-per-use). AWS Lambda, Google Cloud Functions, Vercel Functions là các giải pháp…
- Khi nào chọn SQL và khi nào chọn NoSQL? Các yếu tố quyết định?
SQL (Relational DB): dùng khi cần ACID transactions (tài chính, đặt hàng), data có structure rõ ràng và ổn định, cần complex queries với JOINs. PostgreSQL, MySQL là lựa chọn mặc định tốt cho hầu hết applications. NoSQL chia thành nhiều loại: - Document DB…
- Database Indexing hoạt động như thế nào? Các loại index và khi nào nên dùng?
Index là data structure (thường là B-Tree) cho phép database tìm kiếm records nhanh mà không cần full table scan – giảm query time từ O(n) xuống O(log n). - B-Tree Index: phổ biến nhất, hỗ trợ equality và range queries (=, <, , BETWEEN,…
- Normalization và Denormalization là gì? Trade-off và khi nào dùng mỗi kỹ thuật?
Normalization là quá trình tổ chức database để giảm data redundancy và dependency thông qua các Normal Forms (1NF, 2NF, 3NF, BCNF) – chia data thành nhiều tables liên quan, tránh duplicate data. Lợi ích: storage hiệu quả, dễ maintain consistency khi update (chỉ cần…
- Data Partitioning là gì? Horizontal vs Vertical Partitioning và các chiến lược partition?
- Blob Storage là gì và khi nào dùng thay vì database? Thiết kế hệ thống lưu trữ file?
Blob Storage là storage chuyên biệt cho unstructured data (images, video, docs) — dùng thay vì database để tránh làm DB backup lớn và ảnh hưởng query performance. AWS S3, Google Cloud Storage, Azure Blob Storage là các giải pháp phổ biến. Pattern đúng: lưu…
- Time-Series Database là gì? Khi nào cần dùng và các giải pháp phổ biến?
- Data Lake và Data Warehouse khác nhau như thế nào? Khi nào dùng mỗi loại?
- Change Data Capture (CDC) là gì? Cách hoạt động và use cases? (What is Change Data Capture (CDC)? How it works and use cases?)
- Thiết kế hệ thống URL Shortener (như bit.ly). Các thành phần chính và quyết định kỹ thuật?
- Thiết kế hệ thống Chat real-time (như WhatsApp/Slack). Làm thế nào để handle kết nối và tin nhắn?
- Thiết kế hệ thống Notification (push/email/SMS notifications). Các thành phần và đảm bảo delivery? (Design a Notification System (push/email/SMS). Components and ensuring delivery?)
- Thiết kế Rate Limiter phân tán cho API. Các yêu cầu và giải pháp kỹ thuật?
- Thiết kế News Feed (như Facebook/Twitter). Fanout strategies và caching?
- Thiết kế hệ thống File Storage như Google Drive hoặc Dropbox. Các thành phần chính?
- Thiết kế Search Autocomplete (Typeahead Suggestions). Tối ưu latency và ranking? (Design a Search Autocomplete / Typeahead system. How to optimize latency and ranking?)
- Thiết kế hệ thống Payment như Stripe. Đảm bảo tính chính xác và idempotency? (Design a payment system like Stripe. Ensuring correctness and idempotency?)
- Consistent Hashing là gì và nó giải quyết vấn đề gì so với cách hash modulo (hash(key) % N) thông thường?
Vấn đề với hash(key) % N: khi số node N thay đổi (thêm/bớt 1 server), gần như toàn bộ key bị remap sang node khác → cache miss hàng loạt, rebalance data khổng lồ. Consistent Hashing: đặt cả node và key lên cùng một vòng…
- Idempotency key là gì và làm thế nào để thiết kế một API thanh toán/POST an toàn khi client retry?
Vấn đề: mạng timeout khiến client không biết request đã thành công chưa → retry → tạo double charge / double order. POST vốn không idempotent. Idempotency key: client sinh một key duy nhất (UUID) cho mỗi thao tác nghiệp vụ và gửi qua header…
- Thiết kế hệ thống xác thực với OAuth2/OIDC + JWT: phân biệt access token vs ID token, vì sao Authorization Code Flow + PKCE, và xử lý revoke token thế nào?
- Ba trụ cột của Observability (Logs, Metrics, Traces) khác nhau như thế nào và khi nào dùng cái nào để debug sự cố production?
Observability = khả năng suy ra trạng thái bên trong hệ thống từ output bên ngoài. Ba trụ cột bổ trợ nhau: - Metrics — số liệu tổng hợp theo thời gian (request/s, p99 latency, error rate, CPU). Rẻ, lưu lâu, dùng cho dashboard +…
- Kiến trúc multi-region active-active là gì? Nó khác active-passive ra sao và thách thức lớn nhất khi triển khai là gì?
- Expand-and-contract (parallel change) pattern để migrate schema database không downtime là gì? Mô tả các bước khi đổi tên một cột.
- Hot partition / hot key là gì trong các hệ thống phân tán? Vì sao xảy ra và có những cách nào để giảm nhẹ?
- Thiết kế một hệ thống webhook (như Stripe/GitHub gửi event tới khách hàng): đảm bảo delivery, bảo mật, và chống xử lý trùng như thế nào?
Webhook = HTTP callback do server chủ động đẩy tới endpoint của khách khi có event (đảo chiều polling). Kiến trúc gửi tin cậy: - Event vào queue (Kafka/SQS), worker đọc và POST tới URL khách → tách phát sinh event khỏi việc gửi (gửi…
- Back-of-the-envelope capacity estimation là gì và làm thế nào để ước lượng QPS, storage, bandwidth cho một hệ thống trong buổi phỏng vấn?
Mục đích không là con số chính xác, mà để chọn kiến trúc đúng tầm (cần shard chưa? cache bao nhiêu? vài server hay vài nghìn?). Phỏng vấn viên đánh giá cách bạn suy luận, không phải số thập phân. Quy trình: 1. Bắt đầu…
- Thiết kế News Feed kiểu Twitter: fan-out on write và fan-out on read khác nhau như thế nào, và vì sao phải dùng hybrid cho tài khoản nổi tiếng?
- Thiết kế một web crawler quy mô lớn: các thành phần chính, làm sao tránh crawl trùng và chơi đẹp với server (politeness)?
- Thiết kế hệ thống ghép chuyến kiểu Uber: làm sao đánh chỉ mục vị trí để tìm tài xế gần nhất nhanh, và xử lý cập nhật vị trí real-time?
- Thiết kế dịch vụ streaming video (như YouTube/Netflix): adaptive bitrate streaming với HLS hoạt động ra sao và vai trò của CDN, transcoding là gì?
- CQRS và Event Sourcing là gì? Liên quan nhau ra sao?
- Transactional outbox pattern là gì? Nó giải quyết vấn đề dual-write thế nào?
- Thiết kế một distributed key-value store / cache có khả năng mở rộng (kiểu Dynamo). Bạn tổ chức partitioning, replication và consistency thế nào?
- Thiết kế hệ thống e-commerce (catalog, giỏ hàng, giữ tồn kho, đặt hàng/thanh toán). Các thành phần và điểm nghẽn chính là gì?
- Thiết kế hệ thống đặt vé / chọn ghế (rạp phim, sự kiện). Xử lý concurrency và chống oversell thế nào?
- Thiết kế distributed job/task scheduler (chạy job định kỳ, xử lý task nền). Đảm bảo mỗi job chạy đúng và không trùng thế nào?
- Leader election và consensus là gì? Một cluster thống nhất một leader duy nhất như thế nào (Raft / Paxos)?
- Thiết kế dịch vụ tìm địa điểm gần đây (tìm tài xế/quán ăn quanh bạn). Đánh index không gian (geospatial) thế nào?
- Chính sách eviction của cache khác nhau ra sao — LRU, LFU, TTL? Khi nào chọn cái nào?
Khi cache đầy bộ nhớ, cần bỏ bớt entry để nhận cái mới — chính sách eviction quyết định bỏ cái nào. - LRU (Least Recently Used): bỏ entry lâu nhất chưa được truy cập. Giả định "vừa dùng gần đây thì còn dùng" (temporal…
- Tích hợp VNPay/MoMo: returnUrl và IPN khác nhau thế nào? Bạn dựa vào cái nào để ghi nhận đơn đã thanh toán?
returnUrl là nơi trình duyệt user quay về; IPN là cuộc gọi server-to-server từ cổng thanh toán. Chỉ IPN mới được dùng để chuyển đơn sang trạng thái đã thanh toán. - returnUrl: user được redirect về sau khi trả tiền. Có thể không bao…
- Form đăng ký bị bot tạo hàng nghìn tài khoản ảo mỗi ngày. Bạn xử lý thế nào?
Không có một biện pháp đơn lẻ nào đủ — xếp nhiều lớp, mỗi lớp làm chi phí của bot tăng lên. Lớp chặn trước khi tạo tài khoản: - Rate limit theo IP và theo subnet, ví dụ 5 lượt đăng ký/IP/giờ. Bot dùng…
- Đơn hàng kẹt ở trạng thái pending vì không nhận được IPN từ cổng thanh toán. Bạn xử lý luồng này thế nào?
IPN có thể không tới: server bạn đang deploy, endpoint 500, firewall chặn, hoặc cổng gặp sự cố. Vì vậy không được coi IPN là cơ chế duy nhất — cần một luồng chủ động hỏi lại. Luồng kép (push + pull): 1. Khi tạo…
- Khách yêu cầu huỷ đơn đã thanh toán và hoàn tiền. Bạn thiết kế luồng hoàn tiền (refund) thế nào?
Điểm mấu chốt: refund là một giao dịch riêng, không phải xoá hay sửa giao dịch cũ. Bản ghi thanh toán gốc phải giữ nguyên để đối soát và kế toán. Mô hình dữ liệu: bảng refunds tham chiếu paymentid, gồm amount, reason, status (requested…
- Bạn cho client upload thẳng lên S3 bằng presigned URL. Làm sao biết upload đã xong và làm sao chặn client gửi file sai loại/quá lớn?
Presigned URL cho client PUT thẳng lên S3, server không phải làm proxy dữ liệu — nhưng đổi lại server mất quyền kiểm tra nội dung tại chỗ. Bù lại bằng hai việc: siết ngay trong chữ ký, và xác nhận sau khi upload. Siết…
- Trang danh sách sản phẩm cần tìm theo tên (gõ không dấu vẫn ra), lọc theo nhiều thuộc tính và sắp xếp. Bạn thiết kế thế nào?
Trả lời theo quy mô, đừng nhảy thẳng vào Elasticsearch. Dưới khoảng vài triệu sản phẩm, PostgreSQL làm được cả ba yêu cầu. Tìm không dấu: dùng extension unaccent để bỏ dấu tiếng Việt, và lưu kết quả vào cột sinh sẵn có index, không…
- Sếp yêu cầu biết được "ai đã sửa đơn hàng này, sửa gì, lúc nào". Bạn thiết kế audit log thế nào?
Tách hai khái niệm: audit log ghi lại hành động nghiệp vụ của con người (khác application log dùng để debug). Audit log phải append-only — chỉ thêm, không sửa không xoá. Bảng tối thiểu: Ghi ở đâu: ghi trong cùng transaction với thay đổi…
- Hệ thống có user ở nhiều múi giờ, báo cáo lại chốt theo ngày giờ Việt Nam. Bạn xử lý thời gian thế nào?
Nguyên tắc: lưu UTC, chỉ chuyển đổi ở đầu vào/đầu ra. Trong DB dùng timestamptz (Postgres lưu về UTC), API trả ISO 8601 có offset (2026-08-06T14:30:00+07:00), client hiển thị theo múi giờ của người xem bằng Intl.DateTimeFormat. Dùng timestamp (không tz) là lỗi hay gặp…
- Bài viết cần hiển thị số lượt xem. Mỗi lần mở trang mà `UPDATE posts SET views = views + 1` thì có vấn đề gì? Bạn làm thế nào?
Hai vấn đề: ghi quá nhiều và đếm sai. Ghi quá nhiều: mỗi lượt xem là một UPDATE vào cùng một dòng. Các request cùng lúc xếp hàng chờ khoá dòng đó, và mỗi lần cập nhật sinh một phiên bản dòng mới (Postgres) làm…
- Cuối ngày kế toán báo tổng tiền trên hệ thống lệch với sao kê của cổng thanh toán. Bạn thiết kế luồng đối soát (reconciliation) thế nào?
- Đặt vé xem phim: user chọn ghế rồi có 10 phút để thanh toán. Bạn thiết kế cơ chế giữ chỗ tạm thời thế nào?
- Hệ thống đặt phòng/đặt lịch khám: làm sao đảm bảo hai booking không trùng khoảng thời gian trên cùng một phòng?
- Ngoài phân quyền theo vai trò, hệ thống còn cần "nhân viên chỉ thấy đơn của chi nhánh mình", "khách chỉ thấy đơn của mình". Bạn thiết kế phân quyền theo bản ghi thế nào?
- User yêu cầu xoá tài khoản và toàn bộ dữ liệu cá nhân. Nhưng đơn hàng của họ phải giữ để kế toán. Bạn xử lý thế nào?
- Cho một bài thiết kế hệ thống trong 45 phút, em sẽ tiếp cận theo trình tự nào?
Đừng vẽ kiến trúc ngay. Trình tự được dùng phổ biến gồm 6 bước, mỗi bước có quỹ thời gian riêng: 1. Làm rõ yêu cầu (5-8 phút) — chốt phạm vi: ai dùng, tính năng nào nằm trong scope, tính năng nào bỏ. Xác…
- Yêu cầu chức năng (functional) và phi chức năng (non-functional) khác nhau thế nào? Vì sao phải tách rõ?
Yêu cầu chức năng trả lời "hệ thống làm được gì": người dùng đăng bài, theo dõi người khác, xem bảng tin. Chúng thành các endpoint và bảng dữ liệu. Yêu cầu phi chức năng trả lời "hệ thống phải chạy tốt tới mức nào":…
- Trong 5 phút đầu của buổi thiết kế, em sẽ hỏi những gì để làm rõ đề bài?
Đề bài kiểu "thiết kế Twitter" cố ý mơ hồ — người phỏng vấn muốn xem bạn có tự thu hẹp phạm vi hay không. Bộ câu hỏi nên hỏi: Về phạm vi - Những tính năng nào nằm trong scope buổi này? (đăng bài,…
- Những con số latency nào cần nhớ? Đọc từ RAM, SSD và qua mạng chênh nhau bao nhiêu?
Các bậc độ lớn cần nhớ (số xấp xỉ, dùng để so sánh chứ không phải để trích dẫn chính xác): Thao tác Thời gian ------ Truy cập L1 cache ~1 ns Truy cập main memory (RAM) ~100 ns Đọc 1 MB tuần tự từ…
- Từ 10 triệu người dùng hoạt động hằng ngày, em ước lượng QPS, dung lượng và băng thông như thế nào?
Ước lượng theo bậc độ lớn, làm tròn mạnh, nói rõ từng bước khi làm. Bước 1 — QPS. Một ngày có ~86400 giây, làm tròn 100k giây. Giả sử mỗi người ghi 2 bài/ngày: Với tỷ lệ đọc/ghi 100:1 thì đọc trung bình ~20k…
- p50, p95, p99 là gì? Vì sao đo latency trung bình lại gây hiểu nhầm?
Percentile là ngưỡng mà một tỷ lệ request nhất định nằm dưới nó. p99 = 800 ms nghĩa là 99% request nhanh hơn 800 ms, 1% chậm hơn. Trung bình che giấu phần đuôi. Giả sử 1000 request: 990 request 50 ms, 10 request 5000…
- SLA, SLO, SLI khác nhau thế nào? 99.9% sẵn sàng tương đương bao nhiêu phút downtime?
Ba khái niệm xếp theo tầng: - SLI (Service Level Indicator) — chỉ số đo thực tế: tỷ lệ request trả về thành công, p99 latency, tỷ lệ ghi thành công. Đây là con số lấy từ hệ thống. - SLO (Objective) — mục tiêu…
- Bước thiết kế API trong buổi phỏng vấn nên trình bày ra sao? Cần chốt những gì?
Mục tiêu bước này là chốt API contract giữa client và hệ thống trước khi bàn tới bên trong. Viết 3-5 endpoint chính, mỗi cái một dòng, kèm tham số và giá trị trả về: Những điểm nên chủ động nêu: - Phân trang bằng…
- Ở bước data model, em quyết định những gì và dựa trên căn cứ nào?
Bước này chốt ba việc: thực thể chính, kiểu lưu trữ, và khoá truy cập. 1. Thực thể và quan hệ. Liệt kê 3-5 bảng cốt lõi với các cột quan trọng, không cần đủ. Với bài news feed: users, posts, follows, feeditems. 2. Chọn…
- Single point of failure là gì? Nhìn vào sơ đồ kiến trúc, em rà soát SPOF thế nào?
SPOF là thành phần mà khi nó hỏng thì cả hệ thống hoặc một luồng nghiệp vụ chính dừng hoạt động. Cách rà soát: đi qua từng hộp trên sơ đồ và hỏi "nếu cái này chết bây giờ thì sao". Những chỗ hay bị…
- Vì sao gọi service khác mà không đặt timeout là nguy hiểm? Chọn giá trị timeout dựa trên gì?
Không đặt timeout nghĩa là chấp nhận chờ vô hạn. Khi service phía dưới treo, mỗi request đang chờ vẫn giữ một thread, một kết nối và một chỗ trong connection pool. Chỉ vài chục giây, pool cạn và service của bạn ngừng phục vụ…
- PACELC bổ sung gì so với CAP? Trong thực tế, CAP thường bị hiểu sai ở điểm nào?
- Vì sao một request fan-out ra nhiều service lại chậm hơn nhiều so với từng service? Xử lý phần đuôi thế nào?
- Bulkhead pattern là gì? Nó khác circuit breaker ra sao và liên quan gì tới blast radius?
- Thiết kế cho sự cố nghĩa là gì? Chaos engineering và load shedding đóng vai trò gì?
- Cuối buổi, làm sao xác định điểm nghẽn của thiết kế và trình bày đánh đổi cho thuyết phục?
- Hệ thống đang chạy 1 server, traffic tăng gấp 5 và bắt đầu chậm. Em xử lý theo thứ tự nào?
Trả lời theo thứ tự rẻ và nhanh trước, đừng nhảy thẳng vào phân tán: 1. Đo trước: xem CPU, RAM, disk I/O, số connection DB, latency p95. Chưa biết nghẽn ở đâu thì mọi thay đổi đều là đoán. 2. Sửa nút thắt hiển…
- Sticky session (session affinity) là gì? Vì sao nên tránh và khi nào buộc phải dùng?
Sticky session là cấu hình load balancer luôn đẩy request của cùng một client về đúng một backend, thường bằng cookie do LB phát ra hoặc hash IP nguồn. Vì sao nên tránh: - Tải lệch: một backend hút phải nhóm client nặng thì không…
- Load balancer biết backend nào còn sống bằng cách nào? Health check cấu hình sai gây hậu quả gì?
LB dựa vào health check để quyết định còn gửi request tới backend nào. - Passive (thụ động): quan sát chính lưu lượng thật — backend trả lỗi hoặc timeout liên tiếp quá ngưỡng thì bị đánh dấu hỏng và tạm loại (maxfails / failtimeout…
- Sau khi thêm read replica, user báo "vừa lưu xong mà load lại không thấy". Vì sao và xử lý thế nào?
Đây là replication lag: ghi đi vào primary, đọc lại rơi vào replica chưa kịp áp dụng bản ghi đó. Với replication bất đồng bộ, độ trễ vài chục mili giây là bình thường, nhưng khi replica bận hoặc có một transaction ghi lớn thì…
- Chọn shard key dựa trên tiêu chí gì? Chọn sai thì phải resharding ra sao?
- Đã dùng consistent hashing nhưng tải giữa các node vẫn lệch. Virtual node giải quyết chuyện gì?
- Hot key / hot partition là gì? Phát hiện và xử lý thế nào?
- Đặt giới hạn 100 request/phút mỗi user, nhưng chạy 5 instance thì user gọi được 500. Sửa thế nào?
Nguyên nhân: mỗi instance giữ bộ đếm riêng trong RAM, nên hạn mức bị nhân lên theo số instance — và con số này còn đổi khi autoscaling. Bộ đếm phải nằm ở kho dùng chung, thường là Redis. Token bucket trên Redis cần đọc…
- Queue giúp dàn đều tải lúc cao điểm như thế nào? Queue dài ra liên tục là dấu hiệu gì?
Queue-based load leveling: thay vì để đỉnh tải đập thẳng vào service xử lý, request được đẩy vào hàng đợi và consumer rút ra ở tốc độ ổn định mà hệ thống chịu được. Đỉnh tải biến thành độ trễ chứ không thành lỗi. Hợp…
- Autoscaling nên dựa vào metric nào? Vì sao đã bật autoscaling mà vẫn lỗi lúc cao điểm?
Chọn metric theo bản chất tải: - Service CPU-bound → CPU utilization. - Service I/O-bound (chờ DB, gọi API ngoài) → CPU gần như đứng yên trong khi đã nghẽn; dùng số request đang xử lý đồng thời hoặc RPS mỗi instance. - Worker đọc…
- Scale từ 4 lên 40 instance thì DB báo "too many connections" dù mỗi instance vẫn cấu hình như cũ. Vì sao?
Vì tổng kết nối tới database là số instance × kích thước pool mỗi instance. Pool 20 với 4 instance là 80 kết nối; với 40 instance thành 800, vượt xa maxconnections mặc định của PostgreSQL (100). Đây là cái bẫy cố hữu khi scale…
- Thiết kế cho hệ đọc nhiều và hệ ghi nhiều khác nhau ra sao?
Hỏi tỉ lệ đọc/ghi trước khi vẽ kiến trúc, vì hai hướng tối ưu ngược nhau. Đọc-nặng (mạng xã hội, tin tức, sàn thương mại — đọc thường gấp hàng chục tới hàng trăm lần ghi): - Cache nhiều tầng, CDN cho nội dung công…
- Hệ thống chậm nhưng chưa rõ nghẽn ở đâu. Em tìm nút cổ chai theo cách nào?
- Thiết kế dịch vụ rút gọn link kèm thống kê lượt click cho chiến dịch marketing — em làm thế nào?
Làm rõ yêu cầu trước: ai tạo link (nội bộ marketing, không phải public), link có hạn dùng không, thống kê cần real-time hay trễ vài phút. Giả sử 100k link, 5 triệu click/tháng — tức chỉ ~2 click/giây trung bình, đỉnh chiến dịch có…
- Thiết kế ví điện tử: lưu số dư và giao dịch thế nào để không bao giờ sai tiền?
- Thiết kế hệ thống đặt vé có flash sale: chống bán vượt số lượng và chịu được lượt truy cập tăng đột biến?
- Thiết kế phần danh mục và tìm kiếm sản phẩm cho sàn thương mại điện tử?
Làm rõ quy mô: 5 triệu sản phẩm, vài nghìn shop, traffic đọc gấp hàng trăm lần ghi. Đó là lý do tách đường đọc và đường ghi (CQRS ở mức nhẹ, không cần event sourcing). Dữ liệu gốc nằm ở Postgres: Dùng cột path…
- Thiết kế tính năng theo dõi vị trí shipper theo thời gian thực cho app giao hàng?
Làm rõ trước: khách chỉ xem được shipper của đơn của mình, cần cập nhật mỗi 3-5 giây (không phải 60 lần/giây), và chỉ trong lúc đơn đang giao. Giả sử 20.000 shipper hoạt động, mỗi người ping 5 giây một lần → 4.000 ghi/giây.…
- Thiết kế chat 1-1 và chat nhóm: đảm bảo thứ tự tin nhắn, trạng thái đã đọc và nhận tin khi offline?
Ba yêu cầu quyết định thiết kế: tin nhắn không mất, thứ tự trong một hội thoại phải ổn định, và người offline vẫn nhận đủ khi mở app. Data model — khoá chính đặt đúng là xong nửa bài: seq là số tăng dần…
- Thiết kế bảng tin (news feed) cho app nội dung: dựng feed thế nào khi mới có vài trăm nghìn người dùng?
Câu trả lời đúng ở quy mô này là "đừng vội fan-out". Với vài trăm nghìn user và mỗi người theo dõi vài trăm nguồn, dựng feed lúc đọc (pull) là đủ và ít thành phần phải vận hành nhất. Data model: Dựng feed lúc…
- Thiết kế hệ thống gửi thông báo đa kênh (push, SMS, email): chọn kênh, chống spam và xử lý nhà cung cấp lỗi?
Chốt: service nghiệp vụ không được biết đang gửi bằng kênh nào. Chúng chỉ phát một sự kiện có ý nghĩa nghiệp vụ; việc chọn kênh, dựng nội dung, giới hạn tần suất nằm ở hệ thống thông báo. Luồng: Data model chính: Chọn kênh:…
- Thiết kế đếm lượt xem bài viết và bảng xếp hạng top nội dung trong ngày?
Vấn đề đầu tiên phải nêu: UPDATE posts SET views = views + 1 mỗi lượt xem sẽ khoá cùng một dòng — bài viral biến thành điểm nóng và làm chậm cả bảng. Cách làm: đếm ở Redis, ghi xuống DB theo lô. -…
- Thiết kế luồng upload và xử lý ảnh/video do người dùng đăng lên từ app?
Nguyên tắc mở đầu: file không đi qua API server. Client xin URL ký sẵn (pre-signed URL) rồi upload thẳng lên object storage (S3/GCS/R2). API chỉ cấp quyền và nhận thông báo hoàn tất — nhờ vậy API không bị chiếm băng thông và không…
- Thiết kế hệ thống đặt lịch khám: quản lý khung giờ trống và tránh hai người đặt trùng một slot?
Làm rõ: bác sĩ có lịch làm việc lặp theo tuần, mỗi ca chia thành slot 15-30 phút, có thể nghỉ đột xuất, và bệnh nhân huỷ khá nhiều. Tải rất thấp (vài chục request/giây) nhưng yêu cầu tính đúng đắn cao — đây là…
- Thiết kế rate limiter dùng chung cho nhiều service: đặt ở đâu, thuật toán nào, và khi Redis chết thì sao?
- Thiết kế hệ thống chấm công cho công ty vài nghìn nhân viên (check-in bằng app/máy quét)?
Làm rõ quy mô: 5.000 nhân viên, mỗi người 2-4 lần chấm công/ngày → khoảng 20.000 bản ghi/ngày, dồn vào hai khung giờ ngắn. Tổng tải rất nhỏ; phần khó nằm ở tính đúng đắn và quy tắc nghiệp vụ, không ở scale. Data model:…
- Thiết kế gợi ý tìm kiếm (autocomplete) cho người dùng Việt: gõ không dấu vẫn ra kết quả có dấu, độ trễ dưới 100ms?
- Thiết kế giỏ hàng đồng bộ giữa web và app, kể cả khi người dùng chưa đăng nhập?
Hai câu hỏi làm rõ quyết định toàn bộ: giỏ hàng có cần giữ lại sau khi đóng trình duyệt không (có), và khách chưa đăng nhập có được thêm vào giỏ không (có — bắt đăng nhập trước làm giảm chuyển đổi). Lưu ở…
- Thiết kế hệ thống gợi ý sản phẩm đơn giản khi công ty chưa có đội học máy?
- Team 5 người, sản phẩm mới chạy 6 tháng — có nên tách microservice ngay không?
Thường là không. Lời khuyên phổ biến là monolith first: bắt đầu bằng một monolith được module hoá tốt, tách service chỉ khi có lý do cụ thể. Vì sao chưa nên tách: - Ranh giới nghiệp vụ ở giai đoạn đầu chưa ổn định.…
- Cắt hệ thống thành service theo tiêu chí nào? "Bounded context" nghĩa là gì trong thực tế?
Cắt theo năng lực nghiệp vụ (business capability) / subdomain, không cắt theo tầng kỹ thuật. Bounded context là phạm vi mà một mô hình dữ liệu có nghĩa nhất quán. Ví dụ chữ "Order": - Trong context Bán hàng: Order có giỏ hàng, khuyến…
- Vì sao mỗi service nên có database riêng? Không JOIN được nữa thì xử lý báo cáo thế nào?
Database per service: mỗi service sở hữu schema của mình, service khác chỉ truy cập qua API, không đọc/ghi thẳng bảng. Lý do: - Chia sẻ database làm hai service dính chặt vào cấu trúc bảng. Đổi tên một cột là phải phối hợp deploy…
- Một request lỗi đi qua 5 service, log nằm rải rác 5 nơi — làm sao ghép lại để tìm nguyên nhân?
Hai thứ bắt buộc: correlation id và log tập trung. Correlation id (request id): sinh một id duy nhất ở cửa ngõ (gateway hoặc service đầu tiên), gắn vào header, truyền tiếp qua mọi lời gọi xuống dưới và ghi vào mọi dòng log. Để…
- Màn hình "chi tiết đơn hàng" cần dữ liệu từ Order, User, Payment, Shipping — bạn lấy dữ liệu thế nào?
Hai lựa chọn chính: API composition hoặc CQRS read model. API composition — một thành phần (gateway/BFF/service tổng hợp) gọi từng service rồi ghép kết quả. - Ưu: đơn giản, dữ liệu luôn mới, không cần hạ tầng thêm. - Nhược: latency = chặng chậm…
- Distributed tracing hoạt động thế nào? Trace và span là gì, context truyền qua message queue ra sao?
Trace là toàn bộ hành trình của một request qua hệ thống. Span là một đoạn công việc trong trace (một lời gọi HTTP, một truy vấn DB, một lần xử lý message) — có tên, thời điểm bắt đầu/kết thúc, thuộc tính, và id…
- Service discovery giải quyết vấn đề gì? Chạy trên Kubernetes rồi có còn cần Eureka/Consul không?
Vấn đề: instance của service lên xuống liên tục (autoscale, deploy, container chết và được tạo lại) nên IP/port không cố định. Không thể hardcode địa chỉ trong config. Cơ chế chung: mọi instance đăng ký vào một service registry khi khởi động và gửi…
- Consumer-driven contract test là gì? Vì sao không dựng nguyên hệ thống lên chạy integration test cho chắc?
- Một service phụ thuộc chạy chậm (không chết hẳn) làm cả hệ thống ngừng phục vụ — vì sao và chặn bằng gì?
- Làm saga đặt hàng: chọn choreography hay orchestration, và xử lý ra sao khi bước bù trừ không hoàn tác được?
- Tách dần monolith đang chạy production bằng strangler fig — các bước cụ thể và bẫy dữ liệu là gì?
- Đội nhỏ chuyển sang microservice hay đánh giá thấp chi phí gì? Cần có sẵn năng lực nào trước khi tách?
