Interview on Thanh HV's Blog

Bài 9 — System Design Case Studies

Fri, 03 Jul 2026 16:00:00 +0700

Các chương trước dạy nguyên liệu (cache, queue, shard, replication…). Chương này dạy cách nấu — dẫn dắt một buổi system design 45 phút end-to-end. Khác biệt cốt lõi: system design không kiểm tra bạn biết bao nhiêu công nghệ, mà kiểm tra bạn dẫn dắt sự mơ hồ thành một thiết kế có cơ sở thế nào. Interviewer đóng vai khách hàng mơ hồ; bạn phải hỏi đúng, ước lượng, vẽ, rồi đào sâu.

Bài 8 — Networking, Linux & Kubernetes

Fri, 03 Jul 2026 15:00:00 +0700

Câu 1 — [Fundamental → Senior] TCP hoạt động thế nào? TIME_WAIT là gì và tại sao nó làm cạn kiệt kết nối?

1. Câu hỏi

“Trình bày TCP 3-way handshake và connection lifecycle. TIME_WAIT là gì, tại sao tồn tại, và tại sao nó gây sự cố ‘cannot assign requested address’ trên production?”

2. Interviewer muốn kiểm tra điều gì?

Kiến thức mạng nền tảng — nền của mọi thứ backend, và là nơi phân biệt người hiểu sâu.
Nối được lý thuyết (TCP states) với sự cố thật (port exhaustion, connection pool).
Hiểu tại sao connection reuse (keep-alive, pooling) quan trọng.

3. Câu trả lời ngắn gọn (30 giây)

“TCP thiết lập kết nối qua 3-way handshake (SYN → SYN-ACK → ACK) để hai bên đồng bộ sequence number và xác nhận cả hai gửi/nhận được. Đóng kết nối qua 4 bước (FIN/ACK mỗi chiều). Bên chủ động đóng rơi vào TIME_WAIT ~2×MSL (thường 60s trên Linux) trước khi giải phóng hoàn toàn — để nuốt các packet lạc đường của kết nối cũ và đảm bảo bên kia nhận được ACK cuối. Sự cố: một service mở nhiều kết nối ngắn ra ngoài (mỗi request một connection tới upstream) và chủ động đóng → hàng chục nghìn socket kẹt TIME_WAIT chiếm hết ephemeral port (~28k mặc định) → ‘cannot assign requested address’, không mở được kết nối mới dù CPU/RAM rảnh. Fix gốc: tái sử dụng kết nối (keep-alive, connection pool) để đừng tạo-hủy liên tục.”

Bài 7 — Security & Authentication

Fri, 03 Jul 2026 14:00:00 +0700

Câu 1 — [Fundamental → Senior] JWT vs Session: khác nhau bản chất ở đâu, và tại sao thu hồi JWT lại khó?

1. Câu hỏi

“So sánh session-based auth và JWT. JWT có ưu điểm stateless — nhưng làm sao anh thu hồi (revoke) một JWT trước khi nó hết hạn?”

2. Interviewer muốn kiểm tra điều gì?

Hiểu bản chất stateful vs stateless của hai mô hình, không chỉ “JWT hiện đại hơn”.
Nhận ra ưu điểm lớn nhất của JWT (stateless) chính là nhược điểm lớn nhất (không revoke được) — câu bẫy kinh điển.
Kinh nghiệm thật với refresh token, token rotation, và các đánh đổi.

3. Câu trả lời ngắn gọn (30 giây)

“Session: server lưu trạng thái đăng nhập (session store — Redis/DB), client chỉ giữ session ID; muốn logout/revoke thì xóa ở server — tức thời, nhưng mỗi request phải tra store (stateful, cần chia sẻ store khi scale). JWT: token tự chứa thông tin + chữ ký, server chỉ verify chữ ký không cần tra store — stateless, scale ngang dễ, nhưng không revoke được vì server không giữ trạng thái gì để xóa. Token đã phát là hợp lệ tới khi hết hạn. Giải pháp thực dụng: access token sống ngắn (5–15 phút) + refresh token sống dài lưu ở server (revoke được); muốn revoke ngay thì thêm blocklist — nhưng blocklist khiến JWT không còn stateless nữa, đó chính là nghịch lý.”

Bài 6 — Architecture & System Design

Fri, 03 Jul 2026 13:00:00 +0700

Câu 1 — [Intermediate → Senior] Clean Architecture / Hexagonal Architecture: giải quyết vấn đề gì và khi nào là over-engineering?

1. Câu hỏi

“Trình bày Clean/Hexagonal Architecture. Nó giải quyết vấn đề gì thật sự, và khi nào áp dụng nó là sai lầm?”

2. Interviewer muốn kiểm tra điều gì?

Hiểu nguyên lý gốc (dependency rule) thay vì thuộc tên các vòng tròn.
Đủ trưởng thành để nói về mặt trái — ứng viên chỉ ca ngợi pattern là red flag.
Kinh nghiệm thật: đã thấy cả codebase được cứu lẫn codebase bị giết bởi nó.

3. Câu trả lời ngắn gọn (30 giây)

“Cả hai chung một nguyên lý: business logic không được phụ thuộc vào chi tiết hạ tầng — dependency chỉ theo một chiều, từ ngoài (DB, HTTP, framework) vào trong (domain), thông qua interface (port) do domain định nghĩa và adapter hiện thực ở ngoài. Lợi ích thật: test business logic không cần DB, đổi hạ tầng không đụng domain, và quan trọng nhất — buộc dev phát biểu nghiệp vụ tách khỏi kỹ thuật. Là over-engineering khi: service CRUD mỏng không có nghiệp vụ (interface + 4 layer để bọc một câu SELECT), hoặc team áp dụng máy móc đủ vòng tròn mà không hiểu mục đích — abstraction có giá, chỉ trả khi domain đủ phức tạp để hoàn vốn.”

Bài 5 — Message Queue & API

Fri, 03 Jul 2026 12:00:00 +0700

PHẦN A — MESSAGE QUEUE

Câu 1 — [Intermediate → Senior] Kafka hoạt động thế nào? Tại sao nó đạt throughput hàng triệu message/giây?

1. Câu hỏi

“Kiến trúc Kafka: topic, partition, consumer group, offset. Điều gì cho phép Kafka nhanh như vậy trên phần cứng thường?”

2. Interviewer muốn kiểm tra điều gì?

Hiểu Kafka là distributed log, không phải message queue truyền thống — khác biệt định hình mọi tính chất.
Giải thích được nguồn hiệu năng bằng cơ chế cụ thể (sequential I/O, zero-copy, batching), không phải “Kafka nhanh vì được thiết kế tốt”.
Nắm ordering, rebalance, lag — các khái niệm vận hành hằng ngày.

3. Câu trả lời ngắn gọn (30 giây)

“Kafka là log phân tán: topic chia thành partition, mỗi partition là file log append-only có thứ tự; message không bị xóa khi đọc mà giữ theo retention; consumer tự quản offset của mình. Consumer group chia partition cho các consumer — scale đọc bằng cách thêm consumer tới tối đa = số partition. Nhanh nhờ: ghi/đọc tuần tự trên đĩa (nhanh gần bằng RAM, tận dụng page cache OS), zero-copy (sendfile — dữ liệu từ page cache thẳng ra socket không qua user space), batching + nén cả lô, và broker cực kỳ ’ngu’ — không track trạng thái từng message như RabbitMQ, chỉ là cái log có index.”

Bài 4 — MongoDB, Redis & ClickHouse

Fri, 03 Jul 2026 11:00:00 +0700

PHẦN A — MONGODB

Câu 1 — [Intermediate → Senior] Replica Set hoạt động thế nào? Điều gì xảy ra khi failover?

1. Câu hỏi

“Trình bày cơ chế replica set của MongoDB: bầu chọn, oplog, và các mức write/read concern. Khi primary chết, dữ liệu có thể mất không?”

2. Interviewer muốn kiểm tra điều gì?

Hiểu consensus/election thực tế (Raft-like) chứ không chỉ “có 3 node tự failover”.
Nắm write concern / read concern — nơi ẩn chứa các quyết định mất-hay-không-mất dữ liệu.
Kinh nghiệm với rollback sau failover — thứ ít người biết cho tới khi gặp.

3. Câu trả lời ngắn gọn (30 giây)

“Replica set gồm 1 primary nhận ghi và các secondary kéo oplog (log thao tác idempotent) để replay. Election dựa trên giao thức giống Raft: cần đa số phiếu, node có oplog mới nhất được ưu tiên; vì cần majority nên phải có số node lẻ hoặc arbiter. Có mất dữ liệu không phụ thuộc write concern: w:1 (ack từ primary) — ghi chưa kịp replicate sẽ bị rollback khi failover; w:majority — an toàn qua failover, đổi lấy latency. Read concern và read preference quyết định bạn đọc thấy gì và từ đâu.”

Bài 3 — PostgreSQL

Fri, 03 Jul 2026 10:00:00 +0700

Câu 1 — [Fundamental → Senior] Tại sao PostgreSQL cần MVCC? Nó hoạt động thế nào và cái giá phải trả là gì?

1. Câu hỏi

“Tại sao PostgreSQL cần MVCC? Trình bày cơ chế và hệ quả của nó.”

2. Interviewer muốn kiểm tra điều gì?

Hiểu bài toán gốc: concurrency control — reader và writer tranh chấp thế nào.
Hiểu cơ chế bên trong (tuple version, xmin/xmax, snapshot) chứ không chỉ khẩu hiệu “reader không chặn writer”.
Kinh nghiệm production với hệ quả: bloat, vacuum, wraparound.

3. Câu trả lời ngắn gọn (30 giây)

“Không có MVCC, để đọc dữ liệu nhất quán, reader phải lock chặn writer và ngược lại — throughput sụp đổ khi mixed workload. MVCC giải quyết bằng cách: UPDATE/DELETE không ghi đè mà tạo phiên bản tuple mới; mỗi tuple mang xmin/xmax (transaction tạo/xóa nó); mỗi transaction cầm một snapshot và chỉ ’nhìn thấy’ các version phù hợp snapshot của mình. Kết quả: reader không bao giờ chặn writer. Cái giá: các version chết tích tụ thành bloat, cần VACUUM dọn dẹp, và transaction ID 32-bit cần chống wraparound — đây là nguồn của phần lớn sự cố vận hành Postgres.”

Bài 2 — Node.js Internals

Fri, 03 Jul 2026 09:00:00 +0700

Câu 1 — [Fundamental → Senior] Event Loop hoạt động thế nào? Tại sao Node single-thread mà vẫn xử lý được hàng chục nghìn kết nối?

1. Câu hỏi

“Trình bày các phase của event loop. Node.js ‘single-threaded’ — điều đó đúng đến mức nào?”

2. Interviewer muốn kiểm tra điều gì?

Hiểu mô hình thực thi nền tảng — mọi bug hiệu năng Node đều quy về đây.
Phân biệt được microtask vs macrotask — nguồn của các bug thứ tự thực thi.
Biết giới hạn của mô hình: CPU-bound giết Node như thế nào.

3. Câu trả lời ngắn gọn (30 giây)

“Node chạy JavaScript trên một thread duy nhất, nhưng I/O được libuv ủy quyền cho kernel (epoll/kqueue) hoặc thread pool (mặc định 4 thread cho file I/O, DNS, crypto). Event loop quay qua các phase: timers → pending callbacks → poll (chờ I/O) → check (setImmediate) → close. Giữa mỗi callback, toàn bộ microtask queue (promise, process.nextTick) được xả sạch. Node xử lý được C10K vì thread không bao giờ chờ I/O — nó chỉ chạy callback. Điểm chết: một callback tính toán nặng chặn toàn bộ loop, mọi request khác đứng hình.”

Bài 1 — Golang Internals

Fri, 03 Jul 2026 08:00:00 +0700

Câu 1 — [Fundamental → Senior] Goroutine khác gì OS thread? Giải thích mô hình GPM.

1. Câu hỏi

“Goroutine là gì, khác gì OS thread? Trình bày cách Go scheduler hoạt động (mô hình GPM).”

2. Interviewer muốn kiểm tra điều gì?

Hiểu cơ chế bên trong runtime, không chỉ dùng go func() như hộp đen.
Phân biệt được user-space scheduling vs kernel scheduling.
Biết hệ quả thực tế: khi nào goroutine “rẻ”, khi nào nó gây ra sự cố.

3. Câu trả lời ngắn gọn (30 giây)

“Goroutine là đơn vị thực thi do Go runtime quản lý trong user space, stack khởi đầu ~2KB và co giãn được, chi phí tạo và context switch rẻ hơn OS thread hàng trăm lần. Runtime dùng mô hình GPM: G là goroutine, M là OS thread, P là logical processor giữ run queue. Scheduler multiplex hàng triệu G lên số ít M thông qua P (mặc định P = số CPU core). Nhờ đó Go xử lý được hàng trăm nghìn kết nối đồng thời mà không cần thread pool thủ công.”

Bài 0 — Giới Thiệu Series

Fri, 03 Jul 2026 07:00:00 +0700

Viết bởi góc nhìn của một Principal Software Architect đã phỏng vấn hàng trăm ứng viên Senior/Staff/Principal. Mục tiêu: không phải học thuộc đáp án, mà là học cách tư duy.

Danh sách chương

Chủ đề	Trọng tâm
Golang Internals	GPM, Channel, GC, Escape Analysis, Concurrency Patterns
Node.js Internals	Event Loop, Stream, Worker Thread, Memory Leak
PostgreSQL	MVCC, WAL, Vacuum, Isolation, Planner, Replication
MongoDB, Redis, ClickHouse	Replica Set, Sharding, Distributed Lock, MergeTree
Message Queue & API	Kafka, RabbitMQ, SQS, NATS, REST/gRPC/GraphQL/WebSocket
Architecture & System Design	DDD, Microservices, CQRS, Saga, HA, Multi-region, Observability
Security & Authentication	JWT/Session, OAuth2/OIDC, OWASP, Password/Secrets, mTLS
Networking, Linux/OS & K8s	TCP/TIME_WAIT, HTTP/2/3, TLS, epoll/OOM, Container, Probes, Deploy
System Design Case Studies	Framework 45’, Rate Limiter, URL Shortener, Notification, Payment

Cấu trúc mỗi câu hỏi (11 mục)

Câu hỏi — kèm nhãn độ khó: Fundamental → Intermediate → Senior → Staff → Principal
Interviewer muốn kiểm tra điều gì
Câu trả lời ngắn gọn (30 giây) — elevator answer
Câu trả lời Senior Level (3–5 phút) — Problem → Why → How → Trade-off → Production
Giải thích bản chất — first principles
Trade-off
Ví dụ Production
Những câu trả lời chưa đủ tốt
Sai lầm phổ biến của ứng viên
Follow-up Questions
Liên hệ với Production

Cách interviewer thực sự tư duy — đọc kỹ trước khi ôn

1. Interviewer không tìm người biết đáp án. Họ tìm người hiểu hệ quả.

Khi tôi hỏi “Tại sao PostgreSQL cần MVCC?”, tôi không quan tâm bạn định nghĩa MVCC đúng hay không — Google làm được việc đó. Tôi quan tâm: