GĐ21 — System Design & Scaling (sản phẩm thật + phỏng vấn)

Study note cho FE engineer (JS/TS mạnh) đã học nền tảng backend. Đọc được ngay sau GĐ19 và GĐ20; không cần làm xong các giai đoạn AI (GĐ22–25) trước. Các ví dụ AI SaaS ở đây là case study tự đứng được. Mỗi concept: định nghĩa → tại sao quan trọng → cơ chế → ví dụ → pitfall. Đây là giai đoạn hợp nhất: mọi thứ bạn đã học (index, cache, queue, transaction, observability) giờ được nhìn ở tầng hệ thống. Nó phục vụ hai mục tiêu cùng lúc: quyết định kiến trúc cho sản phẩm của bạn, và trả lời được vòng phỏng vấn system design — vốn là vòng quyết định level (và lương) ở vị trí mid/senior.

Nguyên tắc bao trùm: system design không phải chọn công nghệ xịn nhất. Nó là nêu ra đánh đổi và bảo vệ lựa chọn của mình bằng con số.

1. Khung tư duy — 6 bước, dùng cho cả hai mục tiêu#

Định nghĩa. Một quy trình cố định để đi từ đề bài mơ hồ tới kiến trúc có cơ sở.

Tại sao quan trọng. Cả trong phỏng vấn lẫn ngoài đời, thất bại phổ biến nhất không phải thiếu kiến thức — mà là nhảy thẳng vào vẽ box trước khi biết hệ thống phải làm gì. Người phỏng vấn chấm quy trình nhiều hơn chấm đáp án.

Cơ chế — 6 bước (phỏng vấn 45 phút, phân bổ thời gian kèm theo):

Ví dụ — bước 1 phải hỏi những gì (đề "thiết kế URL shortener"):

Functional:  Rút gọn URL? Custom alias? Hết hạn? Thống kê lượt click?Non-func:    Bao nhiêu link tạo/ngày? Tỉ lệ đọc/ghi? p99 redirect mục tiêu?             Uptime yêu cầu? Được phép mất dữ liệu không?Ràng buộc:   Số người dùng? Toàn cầu hay một vùng? Ngân sách?Ngoài phạm vi: Auth? Chống lạm dụng? Thanh toán?

Câu quan trọng nhất luôn là tỉ lệ đọc/ghi. URL shortener đọc/ghi ≈ 100:1 → kiến trúc xoay quanh cache. Hệ thống phân tích log thì ngược lại → xoay quanh throughput ghi.

Pitfall. Trong phỏng vấn, im lặng suy nghĩ. Người phỏng vấn không đọc được suy nghĩ của bạn — họ chấm lý luận nói ra thành lời. Nói to đánh đổi ngay cả khi chưa chốt: "Có thể cache ở CDN, đổi lại thống kê click sẽ trễ — chấp nhận được nếu số liệu gần đúng là đủ."

2. Ước lượng nhanh — và các con số phải thuộc#

Định nghĩa. Tính nhẩm bậc độ lớn (order of magnitude) để định cỡ hệ thống.

Tại sao quan trọng. Nó quyết định kiến trúc. 100 GB dữ liệu → một Postgres là quá đủ. 100 TB → phải bàn sharding. Không ước lượng thì mọi lựa chọn đều là cảm tính — và bạn sẽ over-engineer, đây là lỗi thường gặp nhất của người mới.

Cơ chế — bảng số phải thuộc lòng. Bảng độ trễ chuẩn chỉ nằm ở một nơi: GĐ19 mục 2 (RAM, SSD, round-trip datacenter, Redis, Postgres, xuyên lục địa, LLM). Đừng học thuộc từng chữ số: chúng là bậc độ lớn (order of magnitude), đổi theo phần cứng và đường truyền. Điều cần nhớ là các khoảng cách giữa chúng: RAM nhanh hơn mạng trong datacenter khoảng 5.000 lần, mạng trong datacenter nhanh hơn xuyên lục địa khoảng 400 lần, và lời gọi LLM chậm hơn mọi thứ còn lại.

Quy đổi hữu ích:

1 triệu request/ngày   ≈ 12 RPS trung bình  → đỉnh thường 3–5× ≈ 50 RPS100 triệu request/ngày ≈ 1.160 RPS          → đỉnh ≈ 5.000 RPS1 năm ≈ 31,5 triệu giây1 hàng Postgres điển hình ≈ 100 B – 1 KB

Ví dụ — ước lượng đầy đủ (URL shortener):

Giả định (ghi ra trước khi tính):  100M link mới/ngày, đọc/ghi = 100:1, mỗi hàng ≈ 500 B (chưa gồm index),  index trên mã ngắn ≈ 40 B/hàng, đỉnh = 5× trung bình,  chưa tính bản sao replicaGhi:  100M / 86.400 ≈ 1.160 WPS   → đỉnh ≈ 5.800 WPS (làm tròn 5.000–6.000)Đọc:  116.000 RPS                 → đỉnh ≈ 580.000 RPS ← con số quyết địnhLưu:  100M × 500 B = 50 GB/ngày → 18,25 TB/năm      100M × 365 = 36,5 TỶ hàng/năm; index ≈ 36,5 tỷ × 40 B ≈ 1,5 TB/năm      giữ 5 năm ≈ 91 TB dữ liệu + 7 TB indexBăng thông đọc: 116k × 500 B ≈ 58 MB/sKết luận rút ra:- ~580k RPS đọc: KHÔNG cách nào để DB gánh → cache là bắt buộc, không phải  tối ưu.- 36,5 tỷ hàng và 18 TB mỗi năm: MỘT Postgres không phải lựa chọn mặc định ở  giả định này. 5 năm ≈ 91 TB chạm ngưỡng "100 TB phải bàn sharding" ở đầu  mục; index của nhiều tỷ hàng không còn nằm trong RAM; vacuum, backup,  restore một bảng cỡ này là gánh nặng vận hành. → Phải thiết kế phân  vùng/shard theo khoá (vd. băm `short_code`) ngay từ đầu, và/hoặc đặt TTL +  chuyển link cũ sang lưu trữ lạnh.- Nếu giả định thực tế thấp hơn (vd. 1M link/ngày): 365 triệu hàng và  ~0,18 TB/năm, ghi ≈ 12 WPS → một Postgres + cache dư sức trong nhiều  năm, KHÔNG cần shard. Con số giả định quyết định kiến trúc; hãy nói ra  giả định trước khi kết luận.- 58 MB/s: bình thường. Băng thông không phải nút thắt.

Trung bình ghi : 100.000.000 / 86.400            = 1.157  ≈ 1.160 WPSĐỉnh ghi (5×)  : 1.157 × 5                       = 5.787  ≈ 5.800 WPSTrung bình đọc : 1.157 × 100                     = 115.741 ≈ 116.000 RPSĐỉnh đọc (5×)  : 115.741 × 5                     = 578.704 ≈ 580.000 RPSDữ liệu/ngày   : 100M × 500 B                    = 50 GBDữ liệu/năm    : 50 GB × 365                     = 18.250 GB = 18,25 TBHàng/năm       : 100M × 365                      = 36,5 tỷIndex/năm      : 36,5 tỷ × 40 B                  = 1,46 TB ≈ 1,5 TB5 năm          : 18,25 × 5 = 91,25 TB dữ liệu ; 1,46 × 5 = 7,3 TB indexBăng thông đọc : 116.000 × 500 B                 = 58 MB/sGiả định thấp (1M link/ngày):  ghi 1.000.000 / 86.400 = 11,6 WPS ; đọc 11,6 × 100 = 1.157 RPS  dữ liệu 1M × 500 B = 0,5 GB/ngày -> × 365 = 0,18 TB/năm ; 365 triệu hàng/năm

Pitfall. Sa vào tính toán chính xác ("86.400 giây × 0,73..."). Làm tròn mạnh tay: 1 ngày ≈ 100.000 giây. Cái người phỏng vấn muốn thấy là kết luận bạn rút ra từ con số, không phải phép chia.

3. Scale dọc vs ngang — và điều kiện tiên quyết#

Định nghĩa. Dọc (vertical) = máy to hơn. Ngang (horizontal) = nhiều máy hơn.

Tại sao quan trọng. Ngành công nghệ có định kiến chống lại scale dọc, và điều đó thường sai. Một máy 64 vCPU / 256 GB RAM ngày nay phục vụ được lượng tải mà năm 2010 cần cả một cụm server — không kèm theo chi phí phức tạp phân tán.

Cơ chế.

• Dọc: đơn giản nhất, không đổi code. Chạm trần phần cứng, và là điểm lỗi đơn (SPOF).
• Ngang: gần như vô hạn, chịu lỗi tốt. Nhưng đòi hỏi stateless và kéo theo mọi vấn đề của hệ phân tán.

Điều kiện tiên quyết của scale ngang — stateless:

// ❌ Trạng thái trong bộ nhớ process → instance B không thấy được của A.// Người dùng bị LB đưa sang instance khác → mất session, mất dữ liệu.const sessions = new Map<string, Session>();const rateLimits = new Map<string, number>();let uploadProgress: Record<string, number> = {};// ✅ Trạng thái chia sẻ nằm ở kho bên ngoàiawait redis.setex(`session:${id}`, 3600, JSON.stringify(session));await redis.incr(`rl:${userId}:${minute}`);

Những chỗ hay giấu trạng thái mà không nhận ra: file upload tạm trên đĩa (GĐ12), cache in-memory, cron chạy trong process app (3 instance = job chạy 3 lần!), WebSocket connection (GĐ09 mục 9; thiết kế chat ở mục 15 của bài này), bộ đếm rate limit.

Pitfall. Nhảy sang Kubernetes + 12 microservice khi mới có 100 người dùng. Bạn trả toàn bộ chi phí phân tán (debug xuyên service, nhất quán cuối, độ trễ mạng, deploy phức tạp) để đổi lấy khả năng scale mà mình chưa cần. Thứ tự đúng: một máy to → thêm read replica → thêm cache → scale ngang tầng app → và chỉ khi ấy mới bàn tách service.

4. Load balancer & tầng biên#

Định nghĩa. LB phân phối request tới nhiều instance, loại bỏ instance hỏng khỏi vòng xoay.

Cơ chế — thuật toán:

• Round-robin — lần lượt. Đơn giản, giả định request có chi phí như nhau.
• Least connections — chọn instance đang rảnh nhất. Tốt hơn cho API có thời gian xử lý chênh lệch lớn (ví dụ endpoint LLM: có request 200 ms, có request 30 s).
• Consistent hashing — cùng khoá tới cùng instance. Dùng cho cache phân tán. Cơ chế, điểm ảo và bẫy khoá nóng, có số đo: mục 13.

Health check — phân biệt hai loại (chi tiết: GĐ09 mục 17, probe trên K8s: GĐ18 mục 5):

// Liveness: process còn sống không? Fail → RESTART container.// Phải SIÊU nhẹ. Đừng check DB ở đây: DB chập chờn sẽ làm restart toàn bộ app,// khiến sự cố nhỏ thành sự cố toàn hệ thống.app.get('/health/live', (_, res) => res.sendStatus(200));// Readiness: sẵn sàng nhận traffic chưa? Fail → LB NGỪNG gửi request (không restart).app.get('/health/ready', async (_, res) => {  const [db, redis] = await Promise.allSettled([pingDb(), pingRedis()]);  const ok = db.status === 'fulfilled' && redis.status === 'fulfilled';  res.status(ok ? 200 : 503).json({ db: db.status, redis: redis.status });});

Pitfall (a) — sticky session. "Ghim người dùng vào một instance" nghe như cách sửa nhanh cho trạng thái in-memory. Thực tế nó phá vỡ scale ngang: tải lệch, deploy làm mất session, instance chết là mất dữ liệu người dùng. Hãy sửa gốc — làm app stateless.

Pitfall (b) — graceful shutdown. Khi deploy, instance nhận SIGTERM. Nếu thoát ngay, các request đang xử lý bị cắt → người dùng thấy lỗi 502 mỗi lần deploy. Mẫu code chuẩn của cả giáo trình nằm ở GĐ09 mục 18; ở tầng hệ thống chỉ cần nhớ thứ tự 4 bước:

1. Đánh dấu đang tắt và để readiness fail → LB ngừng gửi request mới.
2. Chờ việc gỡ instance khỏi LB lan xong (thường vài giây tới 15 giây, tuỳ chu kỳ health check).
3. Ngừng nhận connection mới và await cho request đang chạy hoàn tất (kèm hẹn giờ thoát cưỡng bức nhỏ hơn grace period của orchestrator).
4. Đóng worker queue và DB pool sau khi HTTP đã drain, rồi mới exit.

Thiếu bước 2 là lỗi phổ biến nhất: đóng server ngay lập tức trong khi LB vẫn đang gửi request tới.

Bước 2 làm ở đâu: chọn một nơi, không cộng dồn. Trên Kubernetes, bước 2 do preStop đảm nhiệm (GĐ18 mục 6): app không sleep thêm, vì sleep trong app cộng với preStop làm mỗi lần deploy chờ lâu gấp đôi mà không an toàn hơn. sleep trong app chỉ dành cho nền tảng không có hook tương đương (VM + LB tự quản).

Thứ tự thực tế trên Kubernetes khác danh sách 4 bước ở trên: preStop chạy trước (pod vẫn nhận traffic trong lúc endpoint được gỡ), rồi mới đến SIGTERM, và từ đó app làm bước 3 và 4. Vì endpoint đã được gỡ trong lúc preStop, app không cần tự làm readiness fail rồi chờ như bước 1 và 2; nhánh đó chỉ dành cho nền tảng không có preStop.

 t0           Pod chuyển Terminating   ├─ endpoint controller gỡ pod khỏi Service ──► lan tới kube-proxy/gateway   │      (mất vài giây, pod VẪN nhận request)   └─ kubelet chạy preStop: sleep N giây  <-- bước 2 ở ĐÂY, app không sleep thêm t0+N         kubelet gửi SIGTERM   app: shuttingDown = true; hẹn giờ thoát cưỡng bức (unref)        await server.close()      <- chờ request đang chạy xong (bước 3)        worker.close(); pool.end()  <- SAU khi HTTP đã drain (bước 4)        process.exit(0) t0+grace     SIGKILL nếu chưa thoát Điều kiện (grace = terminationGracePeriodSeconds):   N + (request dài nhất) + (đóng dependency) < grace   và hẹn giờ thoát cưỡng bức trong app < phần grace còn lại sau preStop

5. Mở rộng tầng dữ liệu — thường là nút thắt thật#

Định nghĩa. Tầng app scale ngang dễ (stateless). Database mới là chỗ khó, vì nó có trạng thái.

Cơ chế — thứ tự áp dụng, rẻ trước đắt sau:

(1) Tối ưu truy vấn. Trước khi mua thêm phần cứng: EXPLAIN ANALYZE (GĐ05), thêm index, diệt N+1, bỏ SELECT *. Thường đem lại 10–100× — nhiều hơn mọi bước sau cộng lại, và miễn phí.

(2) Connection pooling. Mỗi connection Postgres là một process riêng tốn ~5–10 MB RAM. Mặc định max_connections = 100. 20 instance app × pool 20 = 400 connection → DB từ chối kết nối.

App (pool nhỏ) → PgBouncer (transaction mode) → Postgres                 1000 client ←→ 20 connection thật

Serverless đặc biệt cần: mỗi lần gọi hàm mở connection mới → cạn ngay. Dùng PgBouncer, Prisma Accelerate, hoặc driver HTTP (Neon).

PgBouncer ở transaction mode không giữ trạng thái phiên giữa các transaction. Theo trang tính năng của PgBouncer (đọc 2026-10-05), SET/RESET, LISTEN, WITH HOLD CURSOR, advisory lock mức session và PREPARE/DEALLOCATE không dùng được; prepared statement mức giao thức dùng được khi đặt max_prepared_statements khác 0. Trang đó không nói về SET LOCAL (chưa xác minh). Cách Prisma phối hợp với PgBouncer (tham số pgbouncer=true trong chuỗi kết nối, chạy migrate qua kết nối trực tiếp) chưa xác minh với Prisma 7: đọc tài liệu Prisma đúng phiên bản bạn dùng trước khi bật.

(3) Read replica. Ghi vào primary, đọc từ replica. Phù hợp vì hầu hết app đọc/ghi ≈ 10:1 trở lên.

// Bẫy "read-after-write": replica trễ vài chục–vài trăm ms.// Người dùng lưu hồ sơ → chuyển trang → đọc từ replica → thấy dữ liệu CŨ → tưởng mất.async function getProfile(userId: string, justWrote: boolean) {  // Đọc ngay sau khi ghi (hoặc trong cùng session người dùng) → ép về primary  return (justWrote ? primary : replica).user.findUnique({ where: { id: userId } });}

(4) Caching. Xem GĐ09 mục 10–11. Ở tầng hệ thống, nhớ thứ bậc cache: trình duyệt → CDN → cache ứng dụng (Redis) → cache của DB. Bắt được ở tầng càng ngoài càng rẻ.

(5) Sharding — biện pháp cuối. Chia dữ liệu theo khoá (thường tenant_id) sang nhiều DB.

• Được: ghi scale gần như tuyến tính.
• Mất: JOIN xuyên shard, transaction xuyên shard, ORDER BY toàn cục, unique toàn cục — tất cả đều mất hoặc trở nên rất đắt. Rebalance shard là dự án nhiều tháng.
• Khi nào: khi một máy lớn nhất không còn gánh nổi lượng ghi. Không phải khi dữ liệu "nhiều".

Ví dụ — chuẩn bị cho sharding mà chưa shard (làm ngay từ đầu, gần như miễn phí):

-- Dùng UUID/ULID thay vì SERIAL: id không đụng nhau khi gộp/tách shard sau này.-- uuidv7() (PostgreSQL 18+): phần đầu theo thời gian nên chèn vào cuối index;-- gen_random_uuid() là UUIDv4 ngẫu nhiên, rải đều khắp index.id UUID PRIMARY KEY DEFAULT uuidv7(),-- MỌI bảng đều có shard key, MỌI query đều lọc theo nótenant_id UUID NOT NULL,

uuidv7() có sẵn từ PostgreSQL 18 (hàm UUID, đọc 2026-10-05); bản cũ hơn thì để ứng dụng sinh UUIDv7 hoặc dùng ULID. Cùng lập luận ở GĐ19 mục 5: thứ tự theo thời gian của id chỉ giúp cục bộ trong index, không phải thứ tự commit.

Điều này cũng chính là thứ đảm bảo tenant isolation trong SaaS nhiều khách hàng (capstone ở GĐ25 dùng đúng cách này) — một mũi tên trúng hai đích.

 Sharding theo tenant_id ┌────────┐   shard = hash(tenant_id) % N │ router │──► shard 0 (tenants A, D) │ (app)  │──► shard 1 (tenants B, E) └────────┘──► shard 2 (tenants C, F) Truy vấn theo tenant (đường nhanh):   app ─► router ─► shard 2 ─► kết quả Truy vấn toàn cục (đường đắt):   app ─► gửi cả 3 shard ─► gộp ─► sắp xếp   (scatter-gather; JOIN/unique toàn cục mất)

Pitfall. Nhảy sang NoSQL để "scale" khi chưa từng chạy EXPLAIN. Phần lớn trường hợp "Postgres chậm" thực ra là thiếu một index. Postgres một máy phục vụ tốt hàng chục nghìn RPS đọc nếu được đánh index đúng — xa hơn nhiều so với nơi hầu hết sản phẩm từng đến.

6. Nhất quán — chọn có ý thức#

Định nghĩa. Strong consistency — đọc luôn thấy lần ghi mới nhất. Eventual consistency — cuối cùng sẽ thấy, tạm thời có thể cũ.

Tại sao quan trọng. Đây là quyết định sản phẩm, không phải kỹ thuật. Đúng câu hỏi phải hỏi là: "Dữ liệu cũ vài giây ở đây gây hại gì?"

Cơ chế — chọn theo trường hợp:

Ví dụ — nơi bắt buộc phải strong:

// Ép DB làm trọng tài, không tin điều kiện kiểm ở tầng app.// Đọc rồi kiểm rồi ghi (read-check-write) ở app luôn có race condition// giữa lúc đọc và lúc ghi khi có 2 request đồng thời.const updated = await prisma.$executeRaw`  UPDATE wallets SET balance_cents = balance_cents - ${amount}  WHERE user_id = ${userId} AND balance_cents >= ${amount}`;   // điều kiện NẰM TRONG câu UPDATEif (updated === 0) throw new InsufficientFundsError();

CAP nói ngắn gọn. Khi mạng giữa các node bị chia cắt (partition — sẽ xảy ra), bạn phải chọn: từ chối phục vụ để giữ nhất quán (CP), hay vẫn phục vụ và chấp nhận dữ liệu lệch (AP). Không có lựa chọn thứ ba. Postgres một primary là CP. DNS là AP.

Pitfall. Nói "hệ thống của tôi eventually consistent" như một đặc điểm kỹ thuật, mà không nói rõ cửa sổ trễ là bao lâu và người dùng thấy gì trong cửa sổ đó. Người phỏng vấn sẽ hỏi đúng câu đó.

7. Chống chịu lỗi — cách hệ thống hỏng#

Định nghĩa. Tập kỹ thuật giữ cho lỗi cục bộ không lan thành sự cố toàn hệ thống.

Tại sao quan trọng. Ở quy mô nhỏ, dependency chết = trang lỗi. Ở quy mô lớn, dependency chậm (chưa chết) là nguy hiểm hơn chết hẳn: request dồn lại, thread/connection cạn, và toàn bộ hệ thống sập dây chuyền vì một service phụ trợ.

Cơ chế — 5 kỹ thuật, theo thứ tự quan trọng:

(1) Timeout — ở MỌI lời gọi ra ngoài. Không có timeout = chờ vô hạn = cạn tài nguyên.

// Timeout phải NGẮN HƠN timeout của tầng gọi bạn — nếu không, client bỏ cuộc// trước, và bạn vẫn giữ tài nguyên cho một request không còn ai chờ.const res = await fetch(url, { signal: AbortSignal.timeout(3000) });

(2) Retry + backoff + jitter.

// Không có jitter: mọi client retry ĐỒNG THỜI sau đúng 1s → tự tạo cơn bão// đánh sập service vừa mới hồi phục ("thundering herd").const delay = Math.min(baseMs * 2 ** attempt, maxMs) * (0.5 + Math.random() * 0.5);

Đã đo ở GĐ19 mục 7: 1.000 client cùng lỗi, không jitter thì đỉnh 1.000 request mỗi 100 ms, full jitter còn 143.

Chỉ retry cái an toàn khi lặp lại: GET, hoặc POST có idempotency key (GĐ09 mục 14). Retry một POST /payments không idempotent = trừ tiền hai lần.

(3) Circuit breaker. Sau N lỗi liên tiếp, ngừng gọi trong T giây và fail nhanh. Bảo vệ cả bạn (không cạn tài nguyên) lẫn dependency (không bị dội request khi đang ngộp).

(4) Bulkhead. Chia tài nguyên theo ngăn, để một phần hỏng không kéo cả tàu chìm. Endpoint LLM (chậm, 30 s) và endpoint CRUD (nhanh, 50 ms) dùng chung một pool thì một đợt tải LLM làm cạn pool, CRUD chết theo dù chẳng liên quan. Cách sửa: mỗi nhóm một ngăn riêng (semaphore giới hạn đồng thời cộng hàng đợi có trần, đầy thì từ chối ngay), hoặc tách hẳn service. Code chạy được nằm ở phần chi tiết bên dưới.

(5) Suy giảm có kiểm soát (graceful degradation). Tính năng phụ chết thì tính năng chính vẫn sống.

// Gợi ý cá nhân hoá chết → trả danh sách phổ biến, KHÔNG trả lỗi 500 cả trang.const recs = await withTimeout(recSvc.get(userId), 200).catch(() => popularItems);

Load shedding — điều phản trực giác. Khi quá tải, chủ động từ chối một phần request (429) là đúng. Nhận hết rồi phục vụ tất cả chậm hơn timeout của client = 0% thành công. Từ chối 30% để 70% thành công là kết quả tốt hơn hẳn.

            lỗi liên tiếp >= ngưỡng   ┌────────┐ ───────────────────────► ┌──────┐   │ CLOSED │                          │ OPEN │ fail nhanh, KHÔNG gọi dependency   └────────┘ ◄─────────────┐          └──┬───┘        ▲        thăm dò OK │             │ hết resetMs        │                ┌──┴──────────┐  │        └────────────────│ HALF-OPEN   │◄─┘  cho 1 lời gọi thăm dò              thăm dò    │ (1 request) │              lỗi: về OPEN└────────────┘

type State = 'closed' | 'open' | 'half-open'export class CircuitOpenError extends Error {}export class CircuitBreaker {  private state: State = 'closed'  private failures = 0  private openedAt = 0  private probing = false  private readonly threshold: number  private readonly resetMs: number  constructor(o: { threshold: number; resetMs: number }) {    this.threshold = o.threshold    this.resetMs = o.resetMs  }  async call<T>(fn: () => Promise<T>): Promise<T> {    if (this.state === 'open') {      if (performance.now() - this.openedAt < this.resetMs) throw new CircuitOpenError()      this.state = 'half-open'      this.probing = false    }    if (this.state === 'half-open') {      if (this.probing) throw new CircuitOpenError()   // đã có một lời gọi thăm dò đang bay      this.probing = true    }    try {      const r = await fn()      this.state = 'closed'; this.failures = 0      return r    } catch (e) {      this.failures++      if (this.state === 'half-open' || this.failures >= this.threshold) {        this.state = 'open'; this.openedAt = performance.now()      }      throw e    } finally {      this.probing = false    }  }}// ---- thử: dependency lỗi, rồi hồi phục ----let dependencyUp = falselet realCalls = 0const dep = async () => {  realCalls++  await new Promise((r) => setTimeout(r, 5))  if (!dependencyUp) throw new Error('500')  return 'ok'}const breaker = new CircuitBreaker({ threshold: 5, resetMs: 100 })const tally = { dependencyError: 0, failFast: 0, ok: 0 }const attempt = async () => {  try { await breaker.call(dep); tally.ok++ }  catch (e) { e instanceof CircuitOpenError ? tally.failFast++ : tally.dependencyError++ }}for (let i = 0; i < 20; i++) await attempt()          // tuần tự, dependency luôn lỗiconsole.log('20 lời gọi, dependency lỗi:', { realCalls, ...tally })await new Promise((r) => setTimeout(r, 120))           // qua resetMsrealCalls = 0; tally.dependencyError = 0; tally.failFast = 0await Promise.all(Array.from({ length: 10 }, attempt)) // 10 lời gọi ĐỒNG THỜI lúc half-openconsole.log('10 lời gọi đồng thời sau resetMs, dependency vẫn lỗi:', { realCalls, ...tally })await new Promise((r) => setTimeout(r, 120))dependencyUp = true; realCalls = 0; tally.ok = 0; tally.dependencyError = 0; tally.failFast = 0await Promise.all(Array.from({ length: 10 }, attempt))console.log('10 lời gọi đồng thời, dependency đã hồi phục:', { realCalls, ...tally })tally.ok = 0; realCalls = 0await attempt()console.log('lời gọi kế tiếp (breaker đã đóng):', { realCalls, ok: tally.ok })

async function callLlm(breaker: CircuitBreaker, run: (s: AbortSignal) => Promise<string>) {  for (let attempt = 0; ; attempt++) {    try {      return await breaker.call(() => run(AbortSignal.timeout(3000)))    } catch (e) {      if (e instanceof CircuitOpenError || attempt >= 2) throw e      const base = Math.min(200 * 2 ** attempt, 2000)      await new Promise((r) => setTimeout(r, base * (0.5 + Math.random() * 0.5)))    }  }}

export class BulkheadFullError extends Error {}export class Bulkhead {  private active = 0  private waiters: (() => void)[] = []  private readonly maxConcurrent: number  private readonly maxQueue: number  constructor(maxConcurrent: number, maxQueue: number) {    this.maxConcurrent = maxConcurrent    this.maxQueue = maxQueue  }  async run<T>(fn: () => Promise<T>): Promise<T> {    if (this.active >= this.maxConcurrent) {      if (this.waiters.length >= this.maxQueue) throw new BulkheadFullError()   // đầy: từ chối ngay      await new Promise<void>((resolve) => this.waiters.push(resolve))         // chờ được nhường chỗ    } else {      this.active++    }    try {      return await fn()    } finally {      const next = this.waiters.shift()      if (next) next()          // nhường chỗ cho người chờ: active giữ nguyên      else this.active--    }  }}// ---- thử: LLM chậm (200 ms) và CRUD nhanh (5 ms) ----const sleep = (ms: number) => new Promise((r) => setTimeout(r, ms))async function burst(llm: Bulkhead, crud: Bulkhead) {  const t0 = performance.now()  const out = { llm: { ok: 0, rejected: 0 }, crud: { ok: 0, rejected: 0, maxMs: 0 } }  const job = (b: Bulkhead, ms: number, k: 'llm' | 'crud') => async () => {    const s = performance.now()    try {      await b.run(() => sleep(ms)); out[k].ok++      if (k === 'crud') out.crud.maxMs = Math.max(out.crud.maxMs, performance.now() - s)    } catch (e) { if (e instanceof BulkheadFullError) out[k].rejected++; else throw e }  }  await Promise.all([    ...Array.from({ length: 10 }, job(llm, 200, 'llm')),   // 10 request LLM tới trước    ...Array.from({ length: 10 }, job(crud, 5, 'crud')),   // rồi 10 request CRUD  ])  return { ...out, crud: { ...out.crud, maxMs: Math.round(out.crud.maxMs / 10) * 10 }, totalMs: Math.round((performance.now() - t0) / 10) * 10 }}const shared = new Bulkhead(2, 2)console.log('chung một ngăn (2 chạy + 2 chờ):', JSON.stringify(await burst(shared, shared)))console.log('tách hai ngăn                   :', JSON.stringify(await burst(new Bulkhead(2, 2), new Bulkhead(10, 10))))

Nhận hết : hàng đợi tăng 120 - 100 = 20 req/s           thời gian chờ > 2 s khi hàng đợi > 100 × 2 = 200 request           200 / 20 = 10 s sau là mọi request mới đều phục vụ muộn hơn 2 s           => client đã bỏ, việc server làm là vô ích: thành công mong đợi ~0%Chặn hàng đợi 200 : nhận tối đa 100 req/s hữu ích           thành công = 100/120 = 83,3%, từ chối (429) = 16,7%

Pitfall. Retry ở mọi tầng, lồng nhau. Client thử tối đa 3 lần (gồm lần đầu) × API gateway 3 lần × service 3 lần = 27 request cho một hành động. Bạn vừa tự DDoS chính mình đúng lúc hệ thống yếu nhất. Quy tắc: retry ở đúng một tầng, thường là tầng ngoài cùng gần người dùng nhất.

8. Đa người thuê & hàng xóm ồn ào#

Định nghĩa. Một tenant tiêu thụ quá nhiều tài nguyên chung làm ảnh hưởng mọi tenant khác.

Tại sao quan trọng. Trong SaaS nhiều khách hàng, một khách hàng import 10 triệu bản ghi làm chậm hệ thống của 500 khách hàng khác. Họ không quan tâm nguyên nhân — họ chỉ thấy sản phẩm của bạn chậm.

Cơ chế.

• Rate limit theo tenant, không chỉ theo IP (GĐ09 mục 6). Hạn mức theo gói dịch vụ.
• Hàng đợi riêng theo mức ưu tiên: job của gói free vào queue riêng, worker riêng, số lượng hạn chế.
• Giới hạn tài nguyên trên mỗi truy vấn: statement_timeout theo tenant; chặn LIMIT quá lớn.
• Cách ly cứng cho khách hàng lớn: khi cần, cho enterprise DB/cụm riêng.

Ví dụ:

// Việc nặng theo lô KHÔNG BAO GIỜ đi chung hàng đợi với việc tương tácawait bulkQueue.add('import', payload, { priority: tenant.plan === 'free' ? 10 : 1 });// worker riêng, concurrency giới hạn → không bao giờ chiếm hết chỗ của việc realtimenew Worker('bulk', handler, { concurrency: 2 });

Pitfall. Chỉ rate limit theo IP. Một tenant doanh nghiệp đứng sau NAT dùng chung một IP → tất cả nhân viên của họ bị chặn oan. Ngược lại, kẻ lạm dụng đổi IP dễ dàng. Rate limit phải theo danh tính (user/tenant/API key), IP chỉ là lớp bổ sung cho request chưa xác thực.

9. Từ monolith tới nhiều service — khi nào, và cái giá thật#

Định nghĩa. Tách một ứng dụng thành nhiều service triển khai độc lập.

Tại sao quan trọng. Đây là quyết định kiến trúc đắt nhất và khó đảo ngược nhất. Và nó thường được đưa ra vì lý do sai.

Cơ chế — lý do đúng và sai:

Cái giá phải trả — nói rõ ra: lời gọi hàm (nano-giây, không bao giờ lỗi) trở thành lời gọi mạng (mili-giây, lỗi thường xuyên). Transaction ACID biến mất → phải dùng saga/outbox. Debug cần distributed tracing. Test local cần dựng 8 service. Mỗi service cần CI/CD, monitoring, on-call riêng.

Đường đi được khuyến nghị: monolith có mô-đun (modular monolith).

src/modules/  billing/     ← ranh giới rõ: chỉ giao tiếp qua interface công khai của module  documents/  auth/

Ranh giới rõ ràng trong một tiến trình. Khi cần tách thật, đường cắt đã sẵn ở đó. Đây gần như luôn là lựa chọn đúng cho một sản phẩm dưới 10 kỹ sư.

Pitfall. Tách theo tầng kỹ thuật (user-service, order-service, notification-service) mà không theo ranh giới nghiệp vụ. Kết quả: mỗi tính năng phải sửa 5 service và deploy đồng bộ — bạn nhận đủ chi phí phân tán mà không có chút độc lập nào. Đó là "distributed monolith", tệ hơn cả monolith lẫn microservice.

10. Quan sát để tìm nút thắt#

Định nghĩa. Hai bộ chỉ số chuẩn: RED cho service (Rate, Errors, Duration) và USE cho tài nguyên (Utilization, Saturation, Errors).

Tại sao quan trọng. Không đo thì mọi tối ưu là đoán. Và ở tầng hệ thống, nút thắt hầu như luôn nằm ở chỗ bạn không ngờ tới.

Cơ chế — cách đọc:

• Đo p50 / p95 / p99, không đo trung bình. Trung bình giấu đi đuôi chậm — mà đuôi chậm chính là trải nghiệm của khách hàng lớn nhất (họ có nhiều dữ liệu nhất).
• Saturation thường cảnh báo sớm hơn utilization: độ dài hàng đợi, số connection pool đang chờ, độ trễ replica.
• Tracing trả lời "3 giây đó tiêu ở đâu" — thứ mà log rời rạc không bao giờ nói được.

Ví dụ — trình tự chẩn đoán "API chậm":

1. p99 chậm nhưng p50 bình thường?   → chỉ một số request; nghi: thiếu index cho tenant dữ liệu lớn, hoặc N+12. Cả p50 lẫn p99 đều chậm?   → tài nguyên bão hoà; xem CPU, pool DB, replica lag3. Chậm dần theo thời gian chạy?   → rò rỉ (memory/connection); so sánh trước/sau restart4. Chậm chỉ vào giờ cao điểm?   → xếp hàng; xem saturation, không xem utilization5. Trace nói thời gian nằm ở đâu?   → DB / gọi ngoài / CPU trong app — ba hướng khác nhau

Pitfall. Cảnh báo dựa trên CPU. CPU 90% có thể hoàn toàn ổn (đang tận dụng tốt), CPU 30% có thể đang chết (chờ I/O). Hãy cảnh báo dựa trên triệu chứng người dùng cảm nhận: p99 latency, tỉ lệ lỗi, độ sâu hàng đợi. CPU chỉ dùng để chẩn đoán sau khi đã có cảnh báo.

11. Case study — AI SaaS ở GĐ25 gánh 100× tải#

Bối cảnh. Đây là case study suy luận, đọc được trước khi làm capstone ở GĐ25. Giả sử có một AI SaaS RAG đa tenant (đúng loại sản phẩm capstone GĐ25 xây) chạy tốt với 1.000 người dùng. Giờ là 100.000. Cái gì vỡ, theo thứ tự?

(1) Vỡ đầu tiên — connection pool DB. Scale app lên 20 instance → 20 × 20 = 400 connection > max_connections. → PgBouncer, pool app nhỏ lại.

(2) Kế tiếp — chi phí và độ trễ LLM. 100× lời gọi LLM = 100× hoá đơn, và rate limit của nhà cung cấp bắt đầu chặn. → Cache ngữ nghĩa (câu hỏi giống nhau → dùng lại kết quả), prompt caching, định tuyến model theo độ khó (model nhỏ cho việc dễ), hàng đợi riêng theo gói, hạn mức cứng theo tenant.

(3) Kế tiếp — vector search. Bảng pgvector lên hàng chục triệu dòng; index IVFFlat bắt đầu chậm. → Chuyển HNSW. Lưu ý lọc theo tenant_id trong pgvector là post-filter: điều kiện WHERE áp dụng sau khi quét index nên có thể trả ít hơn LIMIT (kiểm chứng ngày 2026-10-05, chi tiết ở GĐ23). Bật iterative scan (pgvector 0.8.0 trở lên), partition theo tenant lớn; partial index theo tenant chỉ hợp cho vài tenant rất lớn, còn hàng chục nghìn tenant thì không tạo index riêng cho từng cái (suy ra: mỗi index tốn bộ nhớ và thời gian xây). Cân nhắc vector DB chuyên dụng khi đã đo được là Postgres không kham nổi.

(4) Kế tiếp — worker queue tồn đọng. Job xử lý tài liệu chất đống, người dùng chờ hàng giờ. → Tách queue theo mức ưu tiên, tự động scale worker theo độ sâu hàng đợi, load shedding cho gói free.

(5) Kế tiếp — bảng usage/audit phình. usage_records 500 triệu hàng, báo cáo timeout. → Partition theo tháng (GĐ14 mục 11), bảng tổng hợp sẵn (rollup) cho dashboard, drop partition cũ.

(6) Xuyên suốt — streaming SSE giữ connection lâu. Mỗi request LLM giữ connection 30 giây. → Đây chính là lúc bulkhead cần thiết: tách hẳn service streaming ra khỏi API CRUD; chỉnh timeout ở LB (mặc định 30–60s sẽ cắt giữa chừng câu trả lời).

Điểm mấu chốt cần rút ra. Không có bước nào ở trên bắt đầu bằng "viết lại bằng Go" hay "chuyển sang microservice". Mở rộng quy mô thật là một chuỗi các nút thắt cụ thể, được đo đạc và xử lý từng cái một — theo đúng thứ tự chúng xuất hiện.

12. Chiến thuật phỏng vấn#

Nói to suy nghĩ. Người phỏng vấn chấm quá trình lập luận, không chấm hình vẽ.

Luôn nêu đánh đổi. "Tôi chọn Postgres thay vì Cassandra: ta cần transaction cho thanh toán, và với giả định 1M link/ngày thì dữ liệu chỉ ~0,2 TB/năm, nằm gọn trong một Postgres. Nếu ghi vượt 50k WPS, hoặc lên 100M link/ngày (~18 TB/năm), thì phải shard theo khoá." — Một câu này có giá trị hơn cả một sơ đồ đẹp.

Bắt đầu đơn giản, tiến hoá dần. Vẽ kiến trúc đơn giản chạy được trước, rồi để người phỏng vấn ép bạn scale. Vẽ ngay 15 box là dấu hiệu của over-engineering.

Chủ động nêu điểm yếu. "Ở đây có điểm lỗi đơn. Nếu cần 99,99% uptime thì phải thêm replica standby — có đáng không tuỳ vào yêu cầu."

Biết nói "tôi không biết". "Tôi chưa vận hành Kafka ở quy mô này. Theo hiểu biết của tôi thì nó phù hợp vì X — nhưng tôi sẽ cần đo trước khi cam kết." Thành thật ghi điểm cao hơn tự tin sai.

Quản lý thời gian. Nếu đã 20 phút mà chưa vẽ được gì, bạn đã làm rõ yêu cầu quá lâu. Chốt giả định thành tiếng và đi tiếp.

Pitfall. Đọc thuộc lòng một kiến trúc mẫu học từ video. Người phỏng vấn sẽ thay đổi ràng buộc ("nếu 90% traffic dồn vào 1% tenant thì sao?") và bài học thuộc lòng sụp đổ ngay. Học khung tư duy, đừng học đáp án.

13. Consistent hashing: chia khoá mà không xáo trộn cả hệ#

Định nghĩa. Cách ánh xạ khoá sang node sao cho thêm hoặc bớt một node chỉ di chuyển một phần nhỏ khoá.

Tại sao quan trọng. hash(key) % N đơn giản nhưng đổi N là xáo gần hết khoá: cache phân tán thì mất gần hết dữ liệu nóng cùng lúc (cơn bão cache miss đổ vào DB), shard thì phải di chuyển gần hết dữ liệu.

Cơ chế. Đặt các node lên một vòng số từ 0 đến 2^32. Mỗi khoá băm ra một điểm trên vòng và thuộc node đầu tiên gặp được khi đi theo chiều kim đồng hồ. Thêm node mới chỉ cướp phần vòng nằm ngay trước nó, nên chỉ khoảng 1/(N+1) khoá đổi chỗ, và đều đổ về node mới. Một node trên vòng chỉ có một điểm thì phân bố rất lệch, nên mỗi node được đặt nhiều điểm ảo (virtual node) rải khắp vòng.

import { createHash } from 'node:crypto'const h32 = (s: string) => createHash('sha1').update(s).digest().readUInt32BE(0)// Vòng băm: mỗi node có `vnodes` điểm trên vòng 0..2^32; khoá thuộc điểm gần nhất theo chiều kim đồng hồ.class Ring {  private points: { pos: number; node: string }[] = []  private readonly vnodes: number  constructor(nodes: string[], vnodes: number) {    this.vnodes = vnodes    nodes.forEach((n) => this.add(n))  }  add(node: string) {    for (let i = 0; i < this.vnodes; i++) this.points.push({ pos: h32(`${node}#${i}`), node })    this.points.sort((a, b) => a.pos - b.pos)  }  get(key: string): string {    const h = h32(key)    let lo = 0, hi = this.points.length    while (lo < hi) { const mid = (lo + hi) >> 1; if (this.points[mid]!.pos < h) lo = mid + 1; else hi = mid }    return this.points[lo % this.points.length]!.node     // quá điểm cuối thì quay về điểm đầu  }}const KEYS = Array.from({ length: 100_000 }, (_, i) => `key-${i}`)const nodes4 = ['A', 'B', 'C', 'D']const pct = (x: number) => (x * 100).toFixed(1) + '%'// 1) Thêm node thứ 5: bao nhiêu khoá phải đổi chỗ?const modBefore = KEYS.map((k) => nodes4[h32(k) % 4])const nodes5 = [...nodes4, 'E']const modAfter = KEYS.map((k) => nodes5[h32(k) % 5])const movedMod = KEYS.filter((_, i) => modBefore[i] !== modAfter[i]).length / KEYS.lengthconst ring = new Ring(nodes4, 150)const before = KEYS.map((k) => ring.get(k))ring.add('E')const after = KEYS.map((k) => ring.get(k))const movedRing = KEYS.filter((_, i) => before[i] !== after[i]).length / KEYS.lengthconsole.log('thêm node thứ 5 — hash % N di chuyển:', pct(movedMod), '| vòng băm 150 điểm ảo:', pct(movedRing), '| lý thuyết 1/(N+1):', pct(1 / 5))console.log('khoá di chuyển trong vòng băm đều đổ về node mới E:', KEYS.every((_, i) => before[i] === after[i] || after[i] === 'E'))// 2) Cân bằng tải: tỉ lệ node nặng nhất / nhẹ nhất theo số điểm ảofor (const v of [1, 10, 150]) {  const r = new Ring(nodes4, v)  const load: Record<string, number> = { A: 0, B: 0, C: 0, D: 0 }  KEYS.forEach((k) => load[r.get(k)]!++)  const vals = Object.values(load)  console.log(`${String(v).padStart(3)} điểm ảo/node: nặng nhất ${pct(Math.max(...vals) / KEYS.length)}, nhẹ nhất ${pct(Math.min(...vals) / KEYS.length)}`)}// 3) Khoá nóng: một khoá nhận 30% lưu lượng (vòng băm không cứu được)const r150 = new Ring(nodes4, 150)const traffic = (shards: number) => {  const load: Record<string, number> = { A: 0, B: 0, C: 0, D: 0 }  for (let i = 0; i < 100_000; i++) {    const hot = i % 10 < 3                                       // 30% request vào khoá "viral"    const key = hot ? `viral#${i % shards}` : `key-${i}`         // tách khoá nóng thành `shards` bản    load[r150.get(key)]!++  }  return pct(Math.max(...Object.values(load)) / 100_000)}console.log('node nặng nhất khi có khoá nóng 30% — 1 bản:', traffic(1), '| tách 32 bản:', traffic(32))

Bẫy: khoá nóng (hot key). Vòng băm chia khoá đều, không chia lưu lượng đều. Một link viral, một tenant khổng lồ, một bộ đếm toàn cục thì mọi truy cập vẫn rơi vào một node dù có bao nhiêu điểm ảo (hàng "47,9%" ở bảng trên). Cách xử lý: tách khoá nóng thành nhiều bản (key#0 đến key#K, đọc chọn ngẫu nhiên một bản, ghi cộng dồn rồi gộp), cache cục bộ trong process cho khoá nóng, và phát hiện khoá nóng bằng đo đạc thay vì đoán. Chưa đo ở đây: chi phí gộp khi ghi vào các bản.

Bẫy khác. Khi một node chết, khoá của nó đổ sang node kề trên vòng; node kề đó tăng tải đột ngột (cơn bão miss) và có thể chết theo. Dùng điểm ảo để chia phần dồn đó cho nhiều node thay vì một. Nhân bản (lưu mỗi khoá ở K node liên tiếp trên vòng) là cách Dynamo-style làm; chưa chạy ở đây. Quan hệ với shard: GĐ19 mục 4 giải thích vì sao chia theo khoá và nhân bản là hai việc khác nhau.

14. Một thiết kế hoàn chỉnh: URL shortener theo 6 bước#

Mục này đi hết khung 6 bước của mục 1 trên một đề cụ thể, để bạn thấy mỗi bước sinh ra đầu vào cho bước sau. Giả định như mục 2: 100M link mới mỗi ngày, đọc/ghi 100:1, đỉnh 5× trung bình.

Bước 1. Làm rõ yêu cầu (câu hỏi đã liệt kê ở mục 1). Chốt phạm vi để thiết kế:

Bước 2. Ước lượng (số học ở mục 2): đỉnh đọc khoảng 580.000 RPS nên cache là bắt buộc; 36,5 tỷ hàng và khoảng 18 TB mỗi năm nên phải chia theo khoá; băng thông khoảng 58 MB/s không phải nút thắt. Không gian mã: 7 ký tự base62 cho 62^7 = 3.521.614.606.208 mã (đã tính), 5 năm cần 182,5 tỷ, dư gấp khoảng 19 lần.

Bước 3. API và mô hình dữ liệu.

POST /v1/links    {"url": "...", "alias": "ten-rieng"?, "expiresAt": "..."?}                  header Idempotency-Key (retry không tạo hai mã)  201 {"code": "0004C95", "shortUrl": "https://sho.rt/0004C95"}  409 alias đã có        422 URL không hợp lệ hoặc scheme không phải http/httpsGET /{code}  302 Location: <url dài>  404 không có mã        410 đã hết hạn

CREATE TABLE links (  code       text PRIMARY KEY,         -- cũng là khoá chia shard  url        text NOT NULL,  expires_at timestamptz,  created_at timestamptz NOT NULL DEFAULT now());

Lượt click không ghi vào bảng links (ghi mỗi lượt đọc làm đọc thành ghi): mỗi lần chuyển hướng bắn một event vào queue, worker cộng dồn vào bảng đếm theo ngày. Chặn javascript: và các scheme lạ khi tạo link, nếu không dịch vụ thành công cụ lừa đảo hoặc XSS.

Bước 4. Kiến trúc mức cao.

 client ─► CDN/edge ─► LB ─► app (stateless) ─► Redis: code -> url                                  │ miss                 ▲ điền lại                                  ▼                      │                      Postgres, shard theo code ─────────┘ ghi : app ─ xin dải id ─► bảng id_blocks (một hàng, một DB)       app ─ base62(id) ─► INSERT links click: app ─ event ─► queue ─► worker ─► bảng đếm theo ngày

Bước 5. Đào sâu hai điểm.

Điểm 1: sinh mã. Có ba cách. Băm URL rồi cắt 7 ký tự: va chạm phải kiểm tra lại và cùng URL luôn ra cùng mã (không cho hai người có hai link riêng). Sinh ngẫu nhiên rồi thử lại khi trùng: xác suất trùng mỗi lần thử bằng số mã đã dùng chia 62^7, khoảng 1,0% sau năm đầu (36,5 tỷ) và khoảng 5,2% sau năm năm (182,5 tỷ), tức ghi chậm dần theo thời gian. Cách thứ ba, cấp phát bộ đếm theo dải: mỗi instance xin DB một dải id (ví dụ 1.000), tự phát trong dải rồi đổi sang base62. Không va chạm, DB chỉ bị hỏi một lần mỗi dải. Đánh đổi: mã tuần tự nên đoán được, và instance chết làm bỏ trống phần dải chưa dùng (không sao vì không gian dư lớn). Che thứ tự bằng một phép hoán vị song ánh (id × K) mod 62^7 với K nguyên tố cùng nhau với 62^7; đây là che mắt chứ không phải bảo mật.

const ALPHABET = '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz'  // 62 ký tựexport function toBase62(n: bigint, width = 7): string {  let s = ''  while (n > 0n) { s = ALPHABET[Number(n % 62n)]! + s; n /= 62n }  return s.padStart(width, '0')}// Cấp phát theo dải: mỗi instance xin DB một dải `blockSize` id, rồi tự phát trong dải đó.// Ở Postgres, "xin dải" là một câu: UPDATE id_blocks SET next = next + $1 RETURNING next - $1.class IdAllocator {  private dbNext = 1n  dbCalls = 0  private readonly blockSize: bigint  constructor(blockSize: number) { this.blockSize = BigInt(blockSize) }  lease(): { from: bigint; to: bigint } {    this.dbCalls++    const from = this.dbNext    this.dbNext += this.blockSize    return { from, to: this.dbNext }  }}class Instance {  private cur = 0n  private end = 0n  private readonly alloc: IdAllocator  constructor(alloc: IdAllocator) { this.alloc = alloc }  next(): bigint {    if (this.cur >= this.end) { const b = this.alloc.lease(); this.cur = b.from; this.end = b.to }    return this.cur++  }}// 1) 3 instance phát xen kẽ 30.000 id: có trùng không? DB bị hỏi mấy lần?const alloc = new IdAllocator(1000)const inst = [new Instance(alloc), new Instance(alloc), new Instance(alloc)]const seen = new Set<bigint>()for (let i = 0; i < 30_000; i++) seen.add(inst[i % 3]!.next())console.log('30.000 id từ 3 instance: khác nhau =', seen.size, '| số lần hỏi DB =', alloc.dbCalls)// 2) Độ dài mã theo idconst SPACE = 62n ** 7nconsole.log('62^7 =', SPACE.toString(), '| id 1 tỷ ->', toBase62(1_000_000_000n), '| id 36,5 tỷ ->', toBase62(36_500_000_000n))console.log('5 năm × 36,5 tỷ = 182,5 tỷ; không gian dư gấp', (Number(SPACE) / 182.5e9).toFixed(1), 'lần')// 3) Che thứ tự: hoán vị song ánh id -> (id × K) mod 62^7 với K nguyên tố cùng nhau với 62^7const K = 1_000_003n    // lẻ và không chia hết cho 31 nên là song ánh trên [0, 62^7)const scramble = (id: bigint) => (id * K) % SPACEconst codes = new Set<string>()for (let id = 1n; id <= 1_000_000n; id++) codes.add(toBase62(scramble(id)))console.log('1.000.000 id -> mã khác nhau =', codes.size, '| ví dụ id 1,2,3 ->', [1n, 2n, 3n].map((i) => toBase62(scramble(i))).join(' '))// 4) 10x: số họcconst peakRead = 580_000 * 10, peakWrite = 5_800 * 10console.log('10x: đỉnh đọc', peakRead, 'RPS; hit 99% ->', peakRead * 0.01, 'RPS xuống DB; hit 99,9% ->', peakRead * 0.001)console.log('10x: đỉnh ghi', peakWrite, 'WPS; dải 1000 id ->', peakWrite / 1000, 'lần hỏi DB mỗi giây')

Điểm 2: chuyển hướng và bộ nhớ đệm. 301 được trình duyệt ghi nhớ nên giảm tải nhưng mất số click; 302 mỗi lần về server, đổi lại đếm được. Chọn 302 vì yêu cầu có đếm click. Đường đọc là cache-aside (GĐ09 mục 10): Redis trước, miss mới xuống DB rồi điền lại; lưu cả kết quả "không có mã" với TTL ngắn để người quét mã bậy không đập thẳng vào DB. Phân phối khoá giữa các node Redis dùng consistent hashing (mục 13).

Bước 6. Nút thắt và mở rộng ở 10×. Số học đã chạy: đỉnh đọc 5.800.000 RPS; nếu cache bắt 99% thì 58.000 RPS xuống DB, nếu 99,9% thì 5.800 RPS. Đỉnh ghi 58.000 WPS với dải 1.000 id chỉ là 58 lần hỏi bảng id_blocks mỗi giây, nên bộ cấp id không phải nút thắt. Thứ vỡ trước, theo thứ tự: (1) tỉ lệ cache hit và khoá nóng: một link viral dồn vào một node cache (cách xử lý ở mục 13); (2) DB đọc ở 58.000 RPS nếu hit chỉ 99%: cần replica đọc hoặc chia shard theo code; (3) đường click: nếu đếm từng lượt thì 5,8 triệu event mỗi giây ở đỉnh qua queue là thứ lớn nhất, nên gộp theo lô, lấy mẫu hoặc cộng dồn tại biên trước khi đẩy đi. Cái nào vỡ trước trong thực tế phải do đo, không do đoán (mục 10).

15. Ba case ngắn có đáp án: chat, feed, rate limiter#

Mỗi case: đọc đề, tự làm 15 phút theo 6 bước (giả định ghi ra trước), rồi mở đáp án. Số liệu trong đáp án do tính bằng Node (số học, không phải số đo); mọi giả định ghi rõ và đổi giả định thì kết luận đổi.

Case A: chat 1-1 và nhóm#

Đề. Thiết kế dịch vụ nhắn tin: 50 triệu người dùng hoạt động mỗi ngày, mỗi người gửi 40 tin, mỗi tin khoảng 200 B. Tin phải đến đúng thứ tự trong từng cuộc trò chuyện và không được mất.

Case B: bảng tin (news feed)#

Đề. Thiết kế bảng tin: 100 triệu người dùng, 10 triệu bài đăng mỗi ngày, trung bình mỗi người có 200 người theo dõi. Mở bảng tin phải nhanh; bài mới của người mình theo dõi phải hiện trong vài giây.

Case C: bộ giới hạn tốc độ (rate limiter) phân tán#

Đề. Thiết kế dịch vụ giới hạn tốc độ cho một API với 1 triệu request mỗi giây qua nhiều instance. Mỗi tenant có hạn mức riêng. Vượt hạn mức thì trả 429 kèm Retry-After.

mỗi request hỏi trung tâm (lô 1) : nhận 100, hỏi trung tâm 105 lầnthuê theo lô 10                  : nhận 100, hỏi trung tâm 15 lầnlô 10, chỉ 105 request (sát hạn) : nhận 97, hỏi trung tâm 14 lần

// Bộ giới hạn phân tán: mỗi instance "thuê" token theo lô từ bộ đếm trung tâm (Redis ở thực tế).function mulberry32(seed: number) {  return () => {    seed = (seed + 0x6d2b79f5) | 0    let t = Math.imul(seed ^ (seed >>> 15), 1 | seed)    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t    return ((t ^ (t >>> 14)) >>> 0) / 4294967296  }}class Central {  used = 0  calls = 0  private readonly limit: number  constructor(limit: number) { this.limit = limit }  lease(want: number): number {            // thực tế: một script Lua nguyên tử    this.calls++    const got = Math.min(want, this.limit - this.used)    this.used += got    return got  }}function run(requests: number, instances: number, limit: number, batch: number) {  const rnd = mulberry32(7)  const central = new Central(limit)  const held = new Array<number>(instances).fill(0)  const exhausted = new Array<boolean>(instances).fill(false)   // nhớ "hết hạn mức" tới hết cửa sổ  let admitted = 0  for (let i = 0; i < requests; i++) {    const k = Math.floor(rnd() * instances)                     // LB chia ngẫu nhiên    if (held[k]! === 0 && !exhausted[k]) {      held[k] = central.lease(batch)      if (held[k] === 0) exhausted[k] = true    }    if (held[k]! > 0) { held[k]!--; admitted++ }  }  return { admitted, centralCalls: central.calls }}console.log('mỗi request hỏi trung tâm (lô 1) :', run(300, 5, 100, 1))console.log('thuê theo lô 10                  :', run(300, 5, 100, 10))console.log('lô 10, chỉ 105 request (sát hạn) :', run(105, 5, 100, 10))

Thực hành#

A — Thiết kế trên giấy (mỗi bài 45 phút, bấm giờ, viết ra):

1. URL shortener (kinh điển; luyện ước lượng + cache).

   Lời giải và cách kiểm tra

   Bài 1. URL shortener. Lời giải đầy đủ là thiết kế ở mục 14: đủ 6 bước, API, mô hình dữ liệu, sinh mã có số đo và nút thắt ở 10×. Tự làm trước 45 phút (giả định: 100M link/ngày, đọc/ghi 100:1, đỉnh 5×), rồi so với mục 14. Bài tương tự để luyện thêm: chat, feed, rate limiter ở mục 15.

2. Nền tảng RAG đa tenant — loại sản phẩm capstone ở GĐ25 xây, nhìn ở quy mô 100× (làm trên giấy, không cần có capstone).

   Lời giải và cách kiểm tra

   Bài 2. RAG đa tenant ở 100× (giả định: 100.000 người dùng, mỗi người 20 truy vấn/ngày, 200 chunk/người, vector 1536 chiều).

   • Ước lượng: 100.000 × 20 = 2M truy vấn/ngày ≈ 23 QPS trung bình, đỉnh 5× ≈ 116 QPS. LLM ~10 s mỗi lượt, theo định luật Little (đồng thời = tốc độ đến × thời gian) 116 × 10 ≈ 1.160 stream đồng thời. Vector: 100.000 × 200 = 20M; 1536 × 4 B = 6.144 B nên ≈ 123 GB (float32) hoặc ≈ 61 GB nếu lưu halfvec.
   • Sơ đồ: LB ─► API (CRUD) | service streaming (SSE) riêng ─► pgvector (lọc tenant_id) ─► LLM; ingest qua queue riêng theo gói (mục 11).
   • Đào sâu 1: lọc theo tenant_id áp dụng sau khi quét index (post-filter, kiểm chứng ngày 2026-10-05), nên bật iterative scan, và chỉ dùng partition hoặc partial index cho vài tenant lớn (hàng chục nghìn tenant thì không tạo index riêng cho từng cái). Đào sâu 2: giới hạn rate của nhà cung cấp LLM, dùng hàng đợi theo gói, hạn mức cứng, cache ngữ nghĩa.
   • 10× vỡ trước: 11.600 stream đồng thời giữ kết nối lâu và 1,2 TB vector, nên tách service streaming và cân nhắc kho vector chuyên dụng sau khi đo p99.

3. Hệ thống đo lường sử dụng + tính hạn mức cho SaaS (ghi nhiều, cần chính xác).

   Lời giải và cách kiểm tra

   Bài 3. Đo sử dụng và hạn mức (giả định: 10M sự kiện/ngày, mỗi bản ghi ~100 B).

   • Ước lượng: 10M / 86.400 ≈ 116 sự kiện/s, đỉnh ≈ 580/s; 10M × 100 B = 1 GB/ngày ≈ 365 GB/năm.
   • Thiết kế: nhật ký sự kiện append-only (nguồn sự thật, partition theo tháng) cộng bộ đếm nhanh để chặn hạn mức. Mỗi sự kiện có event_id UNIQUE để idempotent. Kiểm hạn mức: giữ chỗ nguyên tử trong Redis (một script Lua INCRBY rồi so với hạn mức, hoàn lại nếu vượt), ghi sự kiện vào nhật ký, rồi định kỳ đối soát bộ đếm với tổng nhật ký.
   • Đào sâu 1: chính xác so với trễ. Bộ đếm có thể lệch tạm thời nên hạn mức mềm cho phép vượt nhẹ, tiền (billing) tính từ nhật ký chứ không từ bộ đếm. Đào sâu 2: mất Redis thì dựng lại bộ đếm từ nhật ký (rollup).
   • 10× vỡ trước: ghi 5.800/s đỉnh, nên gom ghi theo lô và dùng bảng rollup, không COUNT(*) trên nhật ký thô.

4. Hàng đợi job có ưu tiên và đảm bảo công bằng giữa các tenant.

   Lời giải và cách kiểm tra

   Bài 4. Hàng đợi ưu tiên và công bằng giữa tenant (giả định: 1.000 tenant, 1M job/ngày).

   • Ước lượng: 1M / 86.400 ≈ 11,6 job/s trung bình, đỉnh ≈ 58/s; Redis xử lý dư sức, nút thắt là worker và tenant ồn ào.
   • Thiết kế: queue theo mức ưu tiên (free/pro) với worker và concurrency riêng; trần đồng thời theo tenant (bộ đếm trong Redis, vượt trần thì trì hoãn job); tuổi job tăng dần ưu tiên (aging) để tenant nhỏ không bị bỏ đói.
   • Đào sâu 1: vì sao FIFO chung bất công (một tenant đẩy 10.000 job thì tenant khác chờ sau 10.000 job). Đào sâu 2: công bằng bằng vòng luân phiên có trọng số giữa các tenant, chọn thứ có sẵn trong thư viện bạn dùng (kiểm tra tài liệu BullMQ về nhóm/ưu tiên trước khi cam kết; một số tính năng nhóm là bản trả phí, chưa xác minh).
   • 10× vỡ trước: số tenant hoạt động và độ sâu hàng đợi, nên tự scale worker theo độ sâu hàng đợi và load shedding gói free (mục 7).

Mỗi bài phải có: giả định, ước lượng bằng số, sơ đồ, 2 điểm đào sâu, và mục "cái gì vỡ trước ở 10×".

B — Trên sản phẩm thật (Dự án 3; làm thêm trên capstone nếu bạn đã có): 5. Rà toàn bộ code tìm trạng thái in-memory; chuyển hết sang Redis. Chạy 3 instance sau một LB → xác nhận mọi thứ vẫn đúng (đặc biệt: rate limit và cron không chạy 3 lần).

grep -rnE "new Map\(|setInterval|node-cron|diskStorage|new WebSocketServer|let [a-zA-Z]+ *(=|:) *\{\}" src

const key = `rl:${tenantId}:${Math.floor(Date.now() / 60_000)}`const n = await redis.incr(key)if (n === 1) await redis.expire(key, 60)   // crash giữa hai lệnh làm key sống mãi: dùng SET key 0 EX 60 NX trước, hoặc Luaif (n > limit) return res.status(429).end()

6. Cài graceful shutdown đủ 4 bước. Deploy trong lúc k6 đang bắn tải → xác nhận 0 request lỗi.

   Lời giải và cách kiểm tra

   Mẫu code ở GĐ09 mục 18, sơ đồ thứ tự ở mục 4 của bài này. Nghiệm thu bằng k6 với ngưỡng cứng:

   typescriptReady

   import http from 'k6/http'import { check } from 'k6'export const options = { vus: 20, duration: '60s', thresholds: { http_req_failed: ['rate==0'] } }export default () => { check(http.get(`${__ENV.BASE}/api/ping`), { ok: (r) => r.status === 200 }) }

   Chạy k6 run -e BASE=https://host script.js; trong 60 s đó thực hiện deploy (kubectl rollout restart deployment/api). Mong đợi: http_req_failed 0,00% và ngưỡng đạt; nếu thấy lỗi 502 thì kiểm tra bước 2 (thiếu preStop) trước, rồi bất đẳng thức thời gian ở sơ đồ mục 4.

7. Thêm PgBouncer. Đo số connection trước/sau.

   Lời giải và cách kiểm tra

   textReady

   [databases]app = host=postgres port=5432 dbname=app[pgbouncer]listen_addr = 0.0.0.0listen_port = 6432auth_type = scram-sha-256auth_file = /etc/pgbouncer/userlist.txtpool_mode = transactiondefault_pool_size = 20max_client_conn = 1000

   Chưa chạy: cấu hình tham chiếu, chưa dựng PgBouncer. Đo trước/sau bằng SELECT count(*) FROM pg_stat_activity WHERE datname = 'app'; khi chạy tải. Mong đợi (số học, không phải số đo): trước = số instance × cỡ pool (ví dụ 20 × 20 = 400, vượt max_connections), sau ≤ default_pool_size (20, cộng vài kết nối dự phòng). Trước khi bật transaction mode: SET, LISTEN, advisory lock mức session và PREPARE không dùng được, prepared statement mức giao thức cần max_prepared_statements khác 0 (trang tính năng của PgBouncer, đọc 2026-10-05; SET LOCAL và phần Prisma chưa xác minh, xem mục 5).

8. Thêm timeout + retry có jitter + circuit breaker cho lời gọi LLM (hoặc một API ngoài bất kỳ nếu bạn chưa học GĐ22). Dùng MSW (GĐ13) mô phỏng nhà cung cấp trả 500 → xác nhận hệ thống suy giảm có kiểm soát, không sập.

   Lời giải và cách kiểm tra

   Dùng lớp CircuitBreaker ở mục 7 (đặt trong breaker-lib.ts: phần trước dòng // ---- thử) và callLlm ở đó. Một điểm hay sai: fetch không ném lỗi khi server trả 500, nên hàm run phải tự ném lỗi nếu !res.ok, nếu không breaker không đếm được lỗi nào. Test (MSW 2, Vitest 5):

   typescriptReady

   import { it, expect, beforeAll, afterAll } from 'vitest'import { setupServer } from 'msw/node'import { http, HttpResponse } from 'msw'import { CircuitBreaker, CircuitOpenError } from './breaker-lib.ts'const breaker = new CircuitBreaker({ threshold: 5, resetMs: 30_000 })const run = async (signal: AbortSignal) => {  const res = await fetch('https://llm.test/v1/generate', { method: 'POST', signal })  if (!res.ok) throw new Error(`llm ${res.status}`)   // fetch KHÔNG ném lỗi với 500: phải tự ném để breaker đếm  return await res.text()}async function callLlm(b: CircuitBreaker, fn: (s: AbortSignal) => Promise<string>) {  for (let attempt = 0; ; attempt++) {    try {      return await b.call(() => fn(AbortSignal.timeout(3000)))    } catch (e) {      if (e instanceof CircuitOpenError || attempt >= 2) throw e      const base = Math.min(200 * 2 ** attempt, 2000)      await new Promise((r) => setTimeout(r, base * (0.5 + Math.random() * 0.5)))    }  }}const answer = (q: string) => callLlm(breaker, run).catch(() => `fallback cho ${q}`)let hits = 0const server = setupServer(  http.post('https://llm.test/v1/generate', () => { hits++; return new HttpResponse(null, { status: 500 }) }),)beforeAll(() => server.listen()); afterAll(() => server.close())it('provider 500: trả fallback và breaker mở, không dội provider', async () => {  const out: string[] = []  for (let i = 0; i < 20; i++) out.push(await answer('q'))   // answer() trả fallback khi lỗi  expect(out.every((x) => x.startsWith('fallback'))).toBe(true)  expect(hits).toBeLessThanOrEqual(5)   // breaker nằm trong vòng retry: mỗi lần thử là một lỗi, mở ở lỗi thứ 5  console.log('số lần gọi thật tới provider:', hits)}, 30_000)

   Đã chạy (Node 24.21.0, vitest 5.0.3, msw 2.15.0, tsc --strict sạch): 1 passed, khẳng định số lần gọi thật tới provider không quá 5 và cả 20 câu trả lời đều là fallback. Breaker nằm trong vòng retry: mỗi lần thử là một lỗi, nó mở ở lỗi thứ 5, các lời gọi sau fail nhanh và endpoint vẫn trả lời được.

9. Cài load shedding: khi độ sâu hàng đợi > N, trả 429 kèm Retry-After cho gói free.

   Lời giải và cách kiểm tra

   typescriptReady

   app.use('/api/jobs', async (req, res, next) => {  if (req.tenant.plan === 'free' && (await queue.getWaitingCount()) > MAX_WAITING) {    return res.set('Retry-After', '30').status(429).json({ error: 'overloaded' })  }  next()})

   Nghiệm thu: bơm job đến khi vượt MAX_WAITING, gói free nhận 429 kèm Retry-After, gói trả phí vẫn được nhận. Tính số ở mục 7: chặn ở độ sâu tương ứng thời gian chờ ≤ timeout của client.

10. Dựng dashboard RED: p50/p95/p99, tỉ lệ lỗi, độ sâu hàng đợi, độ trễ replica. Cảnh báo theo p99 và tỉ lệ lỗi, không theo CPU.

p99      : histogram_quantile(0.99,             sum by (le) (rate(http_request_duration_seconds_bucket[5m])))tỉ lệ lỗi: sum(rate(http_request_duration_seconds_count{status=~"5.."}[5m]))           / sum(rate(http_request_duration_seconds_count[5m]))replica lag (trên replica): SELECT now() - pg_last_xact_replay_timestamp();

11. Chạy k6 tăng tải tới khi hỏng. Ghi lại cái gì hỏng trước — hầu như luôn khác với dự đoán của bạn. Sửa. Lặp lại.

export const options = { stages: [  { duration: '2m', target: 50 }, { duration: '2m', target: 200 }, { duration: '2m', target: 500 },] }

Done khi#

• Áp dụng được khung 6 bước cho một đề bài lạ trong 45 phút, có bấm giờ.

  Đáp án

  Làm rõ yêu cầu (5–8'), ước lượng (3–5'), API và dữ liệu (8–10'), kiến trúc mức cao (8–10'), đào sâu 1–2 điểm (10–12'), nút thắt và mở rộng (5'). Cách tự kiểm: bài mẫu ở lời giải Thực hành A có đủ giả định, số, sơ đồ, 2 điểm đào sâu, "vỡ gì ở 10×". Sai thường gặp: 20 phút đầu mới vẽ được hộp. Xem GĐ21 mục 1.

• Thuộc bảng độ trễ; ước lượng QPS/dung lượng bằng nhẩm và rút ra kết luận kiến trúc từ con số.

  Đáp án

  Nhớ các khoảng cách, không nhớ từng số: RAM nhanh hơn round-trip DC ~5.000 lần, DC nhanh hơn xuyên lục địa ~400 lần. Ví dụ rút kết luận: đỉnh đọc 580.000 RPS nên cache là bắt buộc; 18,25 TB/năm nên bàn shard; với 1M link/ngày (0,18 TB/năm) thì không. Xem GĐ19 mục 2 và GĐ21 mục 2.

• Giải thích được vì sao scale dọc thường là bước đúng đầu tiên; nêu được ít nhất 5 chỗ hay giấu trạng thái phá vỡ scale ngang.

  Đáp án

  Máy lớn không đổi code và không có chi phí phân tán; chỉ chạm trần và là SPOF. Chỗ giấu trạng thái: session in-memory, bộ đếm rate limit, file upload tạm trên đĩa, cache in-memory, cron trong process (3 instance chạy 3 lần), WebSocket connection. Xem GĐ21 mục 3.

• Phân biệt liveness vs readiness; giải thích vì sao không check DB trong liveness.

  Đáp án

  Liveness fail thì restart nên phải nhẹ, không chạm DB; nếu DB chập chờn mà liveness check DB, toàn bộ app bị restart và sự cố nhỏ thành sự cố lớn. Readiness fail thì LB ngừng gửi request (không restart) và được phép check DB/Redis. Tự kiểm: /health/live trả 200 khi tắt DB, /health/ready trả 503. Xem GĐ21 mục 4.

• Cài graceful shutdown đủ 4 bước và chứng minh deploy không mất request.

  Đáp án

  Readiness fail, chờ gỡ khỏi LB (trên K8s do preStop, không sleep trong app), await server.close() cùng hẹn giờ thoát cưỡng bức, đóng queue/DB sau khi HTTP drain. Chứng minh: k6 với ngưỡng http_req_failed: rate==0 trong lúc rollout restart, mong đợi 0,00% lỗi (script ở lời giải Thực hành B, mục 6). Sơ đồ thời gian ở GĐ21 mục 4.

• Nêu đúng thứ tự mở rộng tầng dữ liệu (query → pool → replica → cache → shard) và giải thích vì sao sharding là cuối cùng.

  Đáp án

  Query (index, EXPLAIN, N+1; thường 10–100×, miễn phí), pool/PgBouncer, replica, cache, shard. Shard cuối vì mất JOIN, transaction và unique toàn cục xuyên shard và rebalance tốn nhiều tháng (đổi N từ 4 sang 5 với hash % N phải di chuyển 80% dữ liệu). Chỉ shard khi máy lớn nhất không gánh nổi lượng ghi. Xem GĐ21 mục 5.

• Giải thích bẫy read-after-write với replica và cách xử lý.

  Đáp án

  Replica trễ vài chục đến vài trăm ms nên người dùng lưu xong F5 thấy dữ liệu cũ. Xử lý: ép đọc primary ngay sau khi ghi (hoặc N giây trong session), hoặc token LSN. Ví dụ replica trễ 150 ms: đọc ngay sau 30 ms thấy tên cũ, đọc primary thấy mới. Xem GĐ21 mục 5 và GĐ19 mục 4.

• Quyết định strong vs eventual theo từng loại dữ liệu và nêu được hậu quả nghiệp vụ.

  Đáp án

  Số dư, tồn kho, quyền: strong (sai là mất tiền hoặc lỗ hổng); lượt xem, like, feed, tìm kiếm: eventual, nói rõ cửa sổ trễ và người dùng thấy gì trong đó. Strong thật sự nằm ở điều kiện trong câu UPDATE ... WHERE balance >= $x, không ở kiểm tra ở tầng app. Xem GĐ21 mục 6.

• Cài đủ timeout + retry có jitter + circuit breaker; giải thích vì sao chỉ retry ở một tầng.

  Đáp án

  Timeout ở mọi lời gọi ra ngoài và ngắn hơn timeout tầng gọi bạn; retry backoff + jitter chỉ cho thao tác idempotent; breaker mở thì fail nhanh. Ba tầng mỗi tầng 3 lần thử là 27 lần gọi nên chỉ retry ở một tầng. Code và sơ đồ ở GĐ21 mục 7 và GĐ19 mục 7.

• Giải thích load shedding và vì sao từ chối bớt request lại tốt hơn nhận hết.

  Đáp án

  Công suất 100 req/s, đến 120 req/s, client timeout 2 s: nhận hết thì hàng đợi tăng 20 req/s, sau 200/20 = 10 s mọi request đều muộn hơn 2 s, thành công mong đợi ~0%; chặn hàng đợi ở 200 thì 83,3% thành công và 16,7% bị 429. Tính ở GĐ21 mục 7.

• Giải thích consistent hashing: vì sao đổi N với hash % N xáo gần hết khoá, vòng băm và điểm ảo sửa thế nào, và vì sao nó không cứu được khoá nóng.

  Đáp án

  Đã đo (100.000 khoá, 4 lên 5 node): hash % N di chuyển 79,9% khoá, vòng băm 150 điểm ảo di chuyển 21,7% (lý thuyết 1/(N+1) = 20%), và chỉ đổ về node mới. Ít điểm ảo thì lệch (1 điểm: nặng nhất 54,2%, nhẹ nhất 6,2%; 150 điểm: 26,1% và 23,9%). Khoá nóng nhận 30% lưu lượng vẫn làm node chứa nó gánh 47,9%; tách thành 32 bản còn 27,7%. Sai thường gặp: tưởng chia khoá đều là chia tải đều. Xem GĐ21 mục 13.

• Viết ra thiết kế URL shortener đủ 6 bước, có API, mô hình dữ liệu, cách sinh mã có con số và nút thắt ở 10×.

  Đáp án

  Yêu cầu chốt phạm vi; ước lượng cho 580.000 RPS đọc đỉnh nên cache bắt buộc; API POST /v1/links và GET /{code} trả 302; bảng links(code PK, url, expires_at) chia shard theo code; mã sinh từ dải id cấp cho từng instance rồi base62 7 ký tự (62^7 dư gấp khoảng 19 lần nhu cầu 5 năm); ở 10× vỡ trước là tỉ lệ cache hit và khoá nóng, rồi DB đọc, rồi đường đếm click. Tự kiểm: có đủ giả định, số, sơ đồ, hai điểm đào sâu. Xem GĐ21 mục 14.

• Thiết kế được chat, feed và rate limiter ở mức 6 bước, nêu được điểm đào sâu của từng bài.

  Đáp án

  Chat: thứ tự theo từng cuộc trò chuyện (một nơi cấp số thứ tự), at-least-once và khử trùng lặp theo id, kết nối lại có jitter. Feed: ghi trước cho người ít người theo dõi, đọc sau cho người nổi tiếng (50 triệu lần chèn ở 100.000 lần mỗi giây là khoảng 8,3 phút). Rate limiter: bộ đếm Redis nguyên tử, thuê token theo lô (hỏi trung tâm 15 lần thay vì 105 trong thử nghiệm), chọn fail-open hay fail-closed trước khi Redis chết. Xem GĐ21 mục 15.

• Dùng được bulkhead và breaker chỉ cho một lời gọi thăm dò; chỉ ra chúng bảo vệ cái gì.

  Đáp án

  Đã chạy: một ngăn chung thì 10 request CRUD đều bị từ chối vì LLM chiếm hết chỗ; hai ngăn riêng thì CRUD xong cả 10 trong khoảng 10 ms. Breaker half-open cho đúng 1 lời gọi thăm dò trong 10 lời gọi đồng thời, 9 cái fail nhanh. Bulkhead không làm LLM nhanh hơn, nó giữ thiệt hại trong ngăn. Xem GĐ21 mục 7.

• Nêu biện pháp chống noisy neighbor; giải thích vì sao rate limit theo IP là không đủ.

  Đáp án

  Rate limit theo tenant/API key, queue riêng theo gói, statement_timeout và trần LIMIT, cách ly cứng cho enterprise. IP không đủ: nhiều nhân viên một tenant sau cùng NAT bị chặn oan, kẻ lạm dụng đổi IP dễ. Tự kiểm: một tenant bơm 10.000 job không làm tenant khác chờ sau hàng đợi của nó. Xem GĐ21 mục 8.

• Nêu được 4 lý do hợp lệ để tách service và cái giá thật; bảo vệ được lựa chọn modular monolith.

  Đáp án

  Nhiều đội giẫm chân khi deploy, một phần cần scale rất khác (GPU cho LLM), cần công nghệ khác (Python cho ML), cách ly lỗi cho vùng nghiêm ngặt (thanh toán). Cái giá: lời gọi mạng có thể lỗi, mất ACID, cần tracing, N pipeline. Bảo vệ modular monolith: giữ transaction, một stack trace, đường cắt sẵn. Xem GĐ21 mục 9 và GĐ20 mục 3.

• Chẩn đoán "API chậm" theo trình tự có hệ thống; biết vì sao không cảnh báo theo CPU.

  Đáp án

  Trình tự: p99 chậm mà p50 ổn (một số request: thiếu index, N+1), cả hai chậm (bão hoà: pool, replica lag), chậm dần (rò rỉ), chỉ giờ cao điểm (xếp hàng, xem saturation), trace chỉ ra DB/gọi ngoài/CPU. CPU 90% có thể ổn, CPU 30% có thể đang chờ I/O: cảnh báo theo p99 và tỉ lệ lỗi. Xem GĐ21 mục 10.

• Chạy được bài tăng tải tới điểm gãy và tìm ra nút thắt thật.

  Đáp án

  Kịch bản k6 theo bậc (50, 200, 500 VU), ghi p95, lỗi, số kết nối chờ pool, CPU ở mỗi bậc; so với ước lượng trước (pool 10 kết nối × 20 ms/truy vấn cho 500 truy vấn/s). Đạt khi bạn nêu được cái hỏng trước và sửa nó, rồi chạy lại. Kịch bản ở lời giải Thực hành B, mục 11 của GĐ21.

• Trong phỏng vấn: nói to suy nghĩ, nêu đánh đổi, chủ động chỉ ra điểm yếu, nói được "tôi không biết" đúng cách.

  Đáp án

  Nói to lý luận ngay cả khi chưa chốt; luôn nêu đánh đổi bằng con số ("với 1M link/ngày, 0,2 TB/năm nằm gọn một Postgres; lên 100M/ngày, ~18 TB/năm thì shard"); chủ động nêu điểm lỗi đơn; "tôi chưa vận hành X ở quy mô đó, tôi sẽ đo trước khi cam kết". Sai thường gặp: học thuộc kiến trúc mẫu, sụp khi người phỏng vấn đổi ràng buộc. Xem GĐ21 mục 12.

Câu hỏi mở / chưa giải quyết#

• Ngưỡng nào thì đáng tách service streaming LLM khỏi API chính? Phụ thuộc timeout của LB và tỉ lệ request dài — cần đo trên hệ thống thật, không có con số chung.

  Hướng trả lời hiện tại

  Chưa phải kết luận. Đặt điều kiện đo được: tách khi p99 của endpoint CRUD xấu đi vào lúc tải stream cao, hoặc khi số stream đồng thời (tốc độ đến × thời lượng, ví dụ 116 × 10 s ≈ 1.160) làm cạn pool hoặc kết nối của API.

• pgvector tới quy mô nào thì phải chuyển vector DB chuyên dụng? Đo p99 của truy vấn theo số lượng vector, đừng chuyển theo lời đồn.

  Hướng trả lời hiện tại

  Chưa phải kết luận. Vẽ p99 theo số vector và chỉ chuyển khi vượt SLO sau khi đã thử HNSW, iterative scan, partition cho tenant lớn và halfvec.

• Multi-region: độ trễ xuyên lục địa 150–200 ms là giới hạn vật lý. Đáng làm khi nào, và ghi dữ liệu xử lý ra sao (một primary hay multi-primary)? Đây là bài toán lớn — chỉ mở ra khi có khách hàng thật ở vùng khác.

  Hướng trả lời hiện tại

  Chưa phải kết luận. Chỉ đáng khi có khách hàng thật ở vùng khác; khởi đầu thường là một primary, đọc gần người dùng bằng replica/CDN, và chấp nhận ghi xuyên vùng chậm cho tới khi đo được là không chịu nổi.

• Kubernetes: GĐ18 đã dạy K8s, nhưng biết dùng chưa có nghĩa là nên dùng. Ngưỡng hợp lý để chọn K8s thay cho PaaS hoặc ECS là khi đã có nhiều service và nhiều môi trường cần điều phối.

  Hướng trả lời hiện tại

  Chưa phải kết luận. Chọn K8s khi đã có nhiều service và nhiều môi trường cần điều phối, và đội đủ người vận hành nó; trước đó PaaS hoặc ECS đủ dùng và rẻ hơn về công vận hành.