System-Design

Case study cuối cùng có vai trò đặc biệt: Phần 9 đã cho đủ lý thuyết — bài này là bài tập tổng hợp có lời giải, đi qua đúng trình tự một team thật sẽ đi, để bạn đối chiếu với cách tự mình sẽ làm. Đọc theo cách của README Phần 14: dừng sau mỗi mục, tự trả lời trước, rồi so. 1. Business Requirement & Constraint VietShop (Phần 12) ở giai đoạn 6+: 2M user, 800K SKU từ 10K seller. Search hiện tại là PostgreSQL ILIKE từ thời MVP — zero-result rate 22%, CTR search 11%, và đội data chỉ ra: phiên có search chuyển đổi gấp 2.3 lần phiên duyệt — nhưng search đang tệ. Bài toán được duyệt ngân sách như một dự án doanh thu, không phải dự án hạ tầng: đó là cách đúng để bài search được sinh ra. ...

Bài toán định hình: tài nguyên tính toán đắt nhất từng xuất hiện trong tài liệu này (GPU inference đắt hơn CPU serving 10–100×), thời gian xử lý một request dài nhất (giây, không phải mili-giây), và output không tất định. Ba đặc điểm đó bẻ cong nhiều phản xạ đã học — nhưng phần lớn bộ công cụ cũ vẫn đúng, chỉ cần vặn lại hệ số. 1. Business Requirement & Constraint Nền tảng AI nội bộ cho một tập đoàn bán lẻ: các team sản phẩm gọi chung một cửa để dùng LLM (chatbot CSKH, tóm tắt đánh giá, sinh mô tả sản phẩm) và các model nội bộ (phân loại ảnh, dự báo). Kết hợp API bên ngoài (OpenAI/Claude-class) và model tự host trên GPU (model tiếng Việt fine-tune, dữ liệu nhạy cảm không được rời hạ tầng). Team 8 dev/ML. Ràng buộc thống trị: ngân sách GPU + API bill — đây là hệ thống đầu tiên trong tài liệu mà chi phí biến đổi theo từng request đủ lớn để thành NFR số một. ...

Bài toán định hình: một hạ tầng, nghìn khách hàng, và hai lời hứa mâu thuẫn — “dữ liệu của bạn cách ly tuyệt đối” và “giá rẻ nhờ dùng chung”. Multi-tenancy là nghệ thuật giữ cả hai lời hứa cùng lúc — và tenant lớn nhất luôn lớn hơn tenant nhỏ nhất bốn bậc độ lớn (13.2 — luật lũy thừa, lần thứ n). 1. Business Requirement & Constraint SaaS quản lý bán hàng đa kênh cho SME Việt Nam (đơn hàng, kho, khách hàng, báo cáo — kết nối sàn TMĐT): 5.000 tenant từ shop 2 người đến chuỗi bán lẻ 200 cửa hàng. Doanh thu theo gói (freemium → enterprise). Team 12 dev. Ràng buộc sống còn của mô hình SaaS: chi phí phục vụ mỗi tenant phải giảm theo quy mô — nếu mỗi khách mới cần thêm người vận hành, đó là công ty outsourcing đội lốt SaaS. ...

Bài toán định hình: dữ liệu trung tâm (vị trí tài xế) mất giá trị sau vài giây — lần đầu trong tài liệu này, ta gặp dữ liệu mà không lưu mới là thiết kế đúng. Cộng với matching thời gian thực theo không gian — bài toán mà index truyền thống bó tay. 1. Business Requirement & Constraint App gọi xe khu vực (xe máy + ô tô, 3 thành phố lớn VN): khách đặt xe, hệ tìm tài xế gần, khớp lệnh, theo dõi chuyến, tính cước, surge giờ cao điểm. 50K tài xế hoạt động, 500K khách; team 15 dev. Ràng buộc nghiệp vụ khắc nghiệt: matching chậm 5 giây = khách mở app đối thủ — thị trường hai chiều, cả hai phía đều có lựa chọn khác trong túi. ...

Bài toán định hình: video là dữ liệu nặng hơn mọi thứ khác ba bậc độ lớn — một giờ video 1080p ≈ 2–4GB, bằng vài triệu bản ghi DB. Khi dữ liệu nặng đến thế, chi phí băng thông và vị trí đặt byte quyết định kiến trúc nhiều hơn mọi lựa chọn framework. 1. Business Requirement & Constraint Nền tảng video học tập Việt Nam (khóa học quay sẵn + livestream lớp học): giảng viên upload bài giảng, học viên xem theo gói đăng ký. 500K học viên, mục tiêu 2M. Doanh thu theo subscription → trải nghiệm xem (không giật, tua nhanh) là sản phẩm; và chi phí băng thông là dòng chi phí lớn nhất của công ty — tối ưu nó không phải tối ưu kỹ thuật mà là tối ưu biên lợi nhuận. ...

Bài toán định hình: đúng tuyệt đối, chứng minh được, và kiểm toán được — trong khi throughput lại thấp một cách đáng ngạc nhiên. Banking đảo ngược trực giác của mọi case trước: đây là bài mà scale là chuyện phụ, còn từng đồng là chuyện chính. 1. Business Requirement & Constraint Ví điện tử Việt Nam: nạp/rút qua ngân hàng, chuyển tiền P2P, thanh toán QR tại quầy. Ràng buộc đặc thù không case nào trước có: pháp lý là kiến trúc sư trưởng vô hình — giấy phép trung gian thanh toán của NHNN, đối soát bắt buộc với ngân hàng đối tác, audit trail nhiều năm, dữ liệu tại Việt Nam (1.1 §3.2). Sai lệch tiền không phải bug — là sự kiện phải báo cáo. Team 20 dev, trong đó có compliance officer ngồi trong các design review — một vị trí nói lên tất cả. ...

Bài toán định hình: hệ thống không sở hữu chặng cuối — mọi kênh giao (APNs/FCM, SMS, email, Zalo ZNS) đều là bên thứ ba với rate limit, sự cố và hóa đơn của họ. Notification system là bài tổng hợp đẹp nhất của Phần 6 và 13.3/13.5. 1. Business Requirement & Constraint VietShop (Phần 12) đến lúc cần một nền tảng thông báo dùng chung: trước giờ mỗi team tự gửi (order gửi email kiểu này, marketing bắn push kiểu kia) — kết quả là user nhận 14 thông báo/ngày, không tắt được thứ mình ghét, và một chiến dịch marketing từng làm nghẽn luôn đường OTP. Bài toán thật: gom mọi thông báo về một cửa, có luật — ưu tiên, tần suất, sở thích user — và gửi tin cậy qua các kênh không tin được. Team 5 dev, phục vụ 15 team nội bộ như khách hàng. ...

Bài toán định hình: connection dài là state không dọn đi được — chat là nơi nguyên tắc “stateless hóa tầng app” (2.1) gặp giới hạn của nó, và phải thiết kế có state một cách kỷ luật. 1. Business Requirement & Constraint Nền tảng chat cho thương mại (người mua ↔ shop, như chat của sàn TMĐT): hỏi hàng, trả giá, chăm sóc sau bán. Chat tốt = chốt đơn — độ trễ và độ tin của tin nhắn ảnh hưởng trực tiếp GMV. 2M user, 100K shop; team 6 dev. Ràng buộc đặc thù: shop dùng nhiều thiết bị đồng thời (app + web + nhân viên chung tài khoản), lịch sử chat là hồ sơ giao dịch — không được mất. ...

Bài toán định hình: một hành động của một người phải đến với N người theo dõi — và N trải từ 3 đến 10 triệu trên cùng một hệ thống. Không có phân bố nào lệch hơn thế trong toàn bộ tài liệu này. 1. Business Requirement & Constraint Mạng xã hội theo sở thích (cộng đồng thể thao/ẩm thực) tại Việt Nam: user đăng bài, theo dõi nhau, xem feed — dòng nội dung từ những người mình theo. Doanh thu: quảng cáo trong feed → feed là sản phẩm; nghẽn feed = nghẽn doanh thu. Team 8 dev, đã có 200K user sau viral, đang tăng 30%/tháng — bài toán không phải “thiết kế từ zero” mà là “monolith hiện tại bắt đầu oằn ở đâu”. ...

Bài “nhỏ mà thâm”: đủ đơn giản để đi trọn chuỗi tư duy trong một chương, đủ sâu để lộ ra các quyết định thật. Đọc chương này như một bài tập mẫu về cách áp dụng chương 00 — giá trị nằm ở trình tự ra quyết định, không ở sơ đồ cuối. 1. Business Requirement & Constraint Công ty martech Việt Nam cần rút gọn link cho các chiến dịch SMS/social của khách hàng doanh nghiệp: link ngắn tiết kiệm ký tự SMS, đo được lượt bấm, gắn được nhãn chiến dịch. Ràng buộc: team 2 dev, ra mắt trong 6 tuần, chi phí hạ tầng < $200/tháng năm đầu. Doanh thu đến từ gói SaaS theo số link + analytics — nghĩa là đếm click là tính năng ăn tiền, không phải phụ kiện. ...

Mục lục 14.1. URL Shortener — bài tập khởi động hoàn hảo 14.2. Social Network — fan-out và celebrity problem 14.3. Chat Application — triệu kết nối sống 14.4. Notification System — fan-out đa kênh qua những bên không tin được 14.5. Banking & FinTech — khi sai một đồng là sai tất cả 14.6. Video Streaming — băng thông là kiến trúc 14.7. Ride Hailing — geo real-time và dữ liệu phù du 14.8. SaaS Platform — multi-tenancy và noisy neighbor 14.9. AI Platform — GPU đắt và hai chế độ phục vụ 14.10. Search System — Phần 9 trong hành động (E-commerce — case lớn nhất — là toàn bộ Phần 12; Search System đóng vai case tổng hợp của Phần 9.) ...

Năm tình huống: GC Pause, Out of Memory, DNS Failure, Region Outage, Third-party API Down. Nhóm này nhắc một sự thật hay bị quên: dưới mọi kiến trúc đẹp là máy thật, mạng thật, và những công ty khác — tất cả đều hỏng theo lịch của riêng chúng. Case 17 — GC Pause Triệu chứng Latency p99/p999 có răng cưa chu kỳ trong khi p50 đẹp; service “đứng hình” 0.5–30 giây rồi sống lại như chưa có gì; hệ quả dây chuyền đặc trưng: bị văng khỏi consumer group (rebalance), mất leadership (không kịp gia hạn lease), health check fail → bị restart oan — node sống nhưng bị cả cụm đối xử như chết trong đúng khoảng pause (chương 4.4 — “chậm-như-đứt”). ...

Ba tình huống: Cascading Failure, Split Brain, Leader Election Failure. Đây là các sự cố “cấp hệ thống” — không thành phần nào hỏng nặng, nhưng tương tác giữa chúng giết cả hệ thống. Nền lý thuyết: Phần 4. Case 14 — Cascading Failure Triệu chứng Bắt đầu bằng một sự cố nhỏ, cục bộ (một service chậm, một node chết, một deploy xấu) → lan như domino: service A chậm → upstream B cạn thread chờ A → B chậm → C cạn theo… → trong 5–15 phút, toàn hệ thống đỏ, kể cả những service không liên quan gì đến điểm khởi phát. Dashboard nhìn đâu cũng cháy — chính điều đó làm mất phương hướng. ...

Bốn tình huống: Kafka Lag, Message Duplication, Queue Backlog, Retry Storm. Hệ messaging đổi “fail ngay trước mặt” lấy “fail âm thầm phía sau” — sự cố của nó vì thế thường được phát hiện muộn, khi backlog đã thành núi. Case 10 — Kafka Lag (Consumer Lag) Triệu chứng Dữ liệu downstream “cũ dần”: dashboard analytics trễ 40 phút, projection CQRS lệch nguồn sự thật, email gửi sau sự kiện 2 giờ. Metric consumer group lag tăng — quan trọng nhất là tăng đơn điệu không hồi. ...

Sáu tình huống: Database Hotspot, N+1 Query, Deadlock, Replica Lag, Connection Pool Exhaustion, Hot Partition. Database là nơi bottleneck ghé thăm thường xuyên nhất (chương 1.5) — và cũng là nơi sự cố khó scale-out thoát thân nhất. Case 4 — Database Hotspot Triệu chứng DB tổng thể “khỏe” (CPU trung bình 40%) nhưng một nhóm thao tác cụ thể chậm bất thường; lock wait tăng; các query chạm vào một hàng/một trang cụ thể xếp hàng dài. ...

Ba tình huống anh em: Cache Stampede, Cache Avalanche, Thundering Herd. Chung một mô hình gốc — đồng bộ hóa ngẫu nhiên + khuếch đại — khác nhau ở phạm vi và ngòi nổ. Case 1 — Cache Stampede (dogpile trên MỘT key nóng) Triệu chứng Hệ thống êm ả, rồi đúng một khoảnh khắc: DB CPU dựng đứng trong vài giây, latency một nhóm endpoint tăng vọt, sau đó có thể tự hồi phục — lặp lại theo chu kỳ đúng bằng TTL của một key nào đó. Trong slow query log: hàng trăm bản sao của cùng một query trong cùng một giây. ...

21 tình huống sự cố production kinh điển. Mục tiêu không phải ghi nhớ từng ca — mà là nhận ra các mô hình lặp lại để khi gặp biến thể thứ 22, bạn đã có phản xạ đúng. Cấu trúc phân tích mỗi tình huống Mỗi failure case được phân tích theo khung 10 điểm: Triệu chứng — những gì dashboard/user cho thấy Root cause — nguyên nhân gốc Tại sao xảy ra — cơ chế vật lý/logic đằng sau Kiến trúc nào bị ảnh hưởng Metric cần theo dõi Dashboard — nhìn gì Alert — ngưỡng nào Quy trình điều tra — làm gì, theo thứ tự nào Cách khắc phục — cầm máu ngay + chữa gốc Cách phòng tránh Danh mục Nhóm File Các case Caching 13.1 Cache Stampede · Cache Avalanche · Thundering Herd Database 13.2 Database Hotspot · N+1 Query · Deadlock · Replica Lag · Connection Pool Exhaustion · Hot Partition Messaging 13.3 Kafka Lag · Message Duplication · Queue Backlog · Retry Storm Distributed 13.4 Cascading Failure · Split Brain · Leader Election Failure Infrastructure 13.5 GC Pause · Out of Memory · DNS Failure · Region Outage · Third-party API Down Bốn mô hình gốc đằng sau 21 tình huống Đọc xong cả phần, bạn sẽ thấy hầu hết sự cố quy về bốn cơ chế: ...

1. Vấn đề gì xuất hiện? VietShop giờ xử lý GMV mà mỗi giờ downtime = tiền tỷ + tổn hại thương hiệu + điều khoản phạt hợp đồng enterprise. Câu hỏi chuyển từ “làm sao để không sập” (không thể đảm bảo tuyệt đối) sang: “khi thảm họa xảy ra, chúng ta quay lại trong bao lâu, mất bao nhiêu dữ liệu, và ai làm gì?” Thảm họa ở đây không chỉ là region cloud sập. Thống kê ngành nhiều năm cho thấy các nguyên nhân thường gặp hơn: kỹ sư chạy nhầm lệnh xóa trên production, migration hỏng dữ liệu âm thầm suốt 3 ngày, ransomware, tài khoản cloud bị khóa/xâm nhập, bug ứng dụng ghi rác lan qua replication. Lưu ý điểm chung: replication không cứu được bất kỳ ca nào trong số đó — nó trung thành nhân bản cả thảm họa. ...

1. Vấn đề gì xuất hiện? VietShop mở thị trường Indonesia và Thái Lan; đồng thời ký hợp đồng enterprise có cam kết availability cao. Ba áp lực: Vật lý: user Jakarta gọi API đặt tại VN/Singapore: mỗi round-trip +30–70ms; một trang cần 5 round-trip là +350ms — conversion giảm đo được theo từng 100ms. Pháp lý: một số loại dữ liệu người dùng Indonesia phải lưu tại Indonesia. Không phải bài toán hiệu năng — bài toán ranh giới dữ liệu. Rủi ro tập trung: sự cố lớn của một cloud region (đã từng xảy ra với mọi cloud lớn) = 100% hệ thống chết. Board hỏi câu không né được: “nếu region Singapore sập một ngày thì sao?” 2. Vì sao kiến trúc cũ không còn phù hợp? Kiến trúc một region đứng trên giả định “mọi thành phần gần nhau, round-trip ~0.5ms” — giả định thấm vào mọi thiết kế: sync replication rẻ, gọi chéo service thoải mái, một nguồn sự thật cho mọi dữ liệu. Bước ra đa region, tốc độ ánh sáng đập vỡ giả định đó: không thể có đồng thời (1) ghi latency thấp ở mọi region, (2) strong consistency toàn cầu, (3) sống sót khi mất một region — đây là PACELC (chương 4.1) hiện hình bằng tiền và mili-giây. Multi-region không phải “nhân đôi hạ tầng” — nó là chọn lại vị trí trên tam giác đó cho từng loại dữ liệu. ...

1. Vấn đề gì xuất hiện? Seller dashboard (“doanh thu hôm nay, top sản phẩm, đơn chờ xử lý”) join 9 bảng, chạy 3 giây, và chạy trên cùng DB đang phục vụ checkout — mỗi lần seller F5, khách mua hàng chậm đi. Search + filter đa chiều (giá, đánh giá, khoảng cách, khuyến mãi) là loại query mà B-tree index của OLTP không bao giờ phục vụ tốt. Cùng một dữ liệu đơn hàng, giờ có 4 “hình dạng đọc” khác nhau: chi tiết đơn cho user, dashboard cho seller, phân tích cho ops, feature cho ML. Một schema chuẩn hóa không thể tối ưu cho cả 4 — chuẩn hóa vốn được thiết kế để tối ưu cho ghi đúng, không phải cho đọc nhanh. Tỷ lệ đọc:ghi đo được trên các luồng này: > 100:1. 2. Vì sao kiến trúc cũ không còn phù hợp? Một model duy nhất phục vụ hai ông chủ có yêu cầu ngược nhau: bên ghi cần chuẩn hóa, constraint, transaction, ít index (index làm chậm ghi); bên đọc cần denormalize, nhiều index, cấu trúc theo đúng hình dạng màn hình. Tối ưu cho bên này là làm hại bên kia — trên cùng một schema, cuộc giằng co này không có lời giải, chỉ có thỏa hiệp ngày càng tệ ở cả hai phía. ...

1. Vấn đề gì xuất hiện? Sau 1 năm microservices, một dạng coupling mới mọc lên — coupling tích hợp: Khi đơn hàng được tạo, Order service phải biết và gọi: Email, Inventory, Analytics, Loyalty, Fraud, Recommendation. Thêm consumer thứ 7 = sửa code + deploy Order service. Producer lệ thuộc vào danh sách người nghe — ngược đời. Availability của “tạo đơn” = tích availability của 6 downstream (hoặc code retry/degrade cho từng cái, ×6). Team Analytics muốn đi lại lịch sử đơn hàng để tính lại metric — không thể: các lời gọi HTTP đã bay hơi, dữ liệu chỉ còn trạng thái cuối trong DB. RabbitMQ hiện tại: message tiêu thụ xong là biến mất — không phục vụ được nhu cầu “nhiều consumer độc lập, mỗi bên đọc theo nhịp riêng, replay được”. 2. Vì sao kiến trúc cũ không còn phù hợp? Mô hình “A gọi B” (dù sync HTTP hay qua work queue) mã hóa cứng ai cần biết điều gì vào producer. Số tuyến tích hợp tăng như N×M. First principles: sự kiện nghiệp vụ (“đơn #123 đã tạo”) là một sự thật — sự thật nên được công bố một lần và ai quan tâm thì tự đến đọc, thay vì được giao tận tay từng người. Đảo ngược hướng phụ thuộc: producer không biết consumer tồn tại. ...

1. Vấn đề gì xuất hiện? VietShop: 1M+ user, 60 dev / 8 team, modular monolith kỷ luật tốt. Ba áp lực mới mà “một deployable” không giải được: Nhịp deploy xung đột: team Search muốn deploy 5 lần/ngày để tune ranking; team Payments bị ràng buộc quy trình kiểm soát thay đổi nghiêm ngặt. Chung một deployable = Search bị Payments ghìm, Payments bị Search làm rủi ro. Nhu cầu tài nguyên xung đột: Search cần máy RAM lớn + Elasticsearch; xử lý ảnh cần CPU; API thường cần nhiều instance nhỏ. Một deployable = mọi instance mang mọi thứ. Bán kính sự cố chung: memory leak ở module khuyến mãi làm OOM cả app — gồm cả checkout. Một bug của team này đánh sập doanh thu của mọi team. 2. Vì sao kiến trúc cũ không còn phù hợp? Modular monolith đã giải bài toán ranh giới code nhưng ba tài nguyên vẫn dùng chung không tách được: tiến trình runtime (crash chung, GC chung, leak chung), pipeline deploy (nhịp chung, rollback chung), cụm hạ tầng (shape máy chung). Khi các module cần khác nhau về runtime, nhịp deploy, hình dạng hạ tầng — chỉ tách tiến trình mới giải được. Đó chính xác là (và chỉ là) điều microservices mang lại: ranh giới deploy độc lập. ...

1. Vấn đề gì xuất hiện? Công ty 25 dev, 4 nhóm tính năng. Hệ thống chạy ổn — vấn đề nằm ở việc phát triển nó: Build + test 25 phút; deploy 2 lần/tuần theo “chuyến tàu”, ai lỡ thì chờ. Thay đổi module khuyến mãi làm gãy checkout — vì code checkout import thẳng vào class nội bộ của khuyến mãi từ 2 năm trước. Không ai dám nói “tôi hiểu toàn bộ hệ thống”. Onboarding dev mới: 2 tháng. Ranh giới thư mục từ giai đoạn 1 đã xói mòn: 400 điểm import chéo giữa các “module”, 60 bảng DB mà module nào cũng đọc của nhau. Bottleneck bây giờ là coupling — đo bằng tốc độ ra feature và tỷ lệ regression liên-module, không phải bằng CPU. ...

1. Vấn đề gì xuất hiện? ~200K user, GMV bắt đầu có ý nghĩa, flash sale đầu tiên sắp chạy. Ba vấn đề với queue-trên-Redis hiện tại: Đảm bảo mỏng manh: một sự cố Redis đã làm mất ~2000 job trong 30 giây, trong đó có job cập nhật trạng thái thanh toán — team mất 2 ngày đối soát tay với cổng thanh toán. Thiếu công cụ xử lý lỗi trưởng thành: job fail 5 lần thì đi đâu? Ai xem? Retry với backoff + dead letter + đánh chỉ mục lỗi phải tự chế. Flash sale sắp tới: ước 10× peak vào endpoint đặt hàng trong 5 phút. Web + DB không nên (và không cần) được scale cho đỉnh 5 phút đó — cần một tầng hấp thụ spike và cho phép xử lý với tốc độ của hệ thống. 2. Vì sao kiến trúc cũ không còn phù hợp? Redis-queue là cache được nhờ vả làm broker. Nó thiếu các thuộc tính mà bài toán mới đòi: durability có cam kết (ghi disk, replicate trước khi ack), acknowledgement chuẩn (consumer chết giữa chừng → message quay lại queue), dead letter queue, routing, priority, và backpressure rõ ràng. Vá từng thiếu hụt bằng code tự chế = tự viết một message broker tồi. ...

1. Vấn đề gì xuất hiện? ~100K user. Triệu chứng: Endpoint đặt hàng p99 = 4 giây. Tracing bóc ra: logic đơn hàng 150ms, gửi email xác nhận 800ms, gọi API đối tác vận chuyển 1.2s, bắn thông báo 500ms — 2.5s là việc user không cần chờ. Upload ảnh sản phẩm của seller treo 8–15 giây (resize 5 kích cỡ trong request). Khi SMTP provider chậm (chuyện của họ, không phải của ta), toàn bộ endpoint đặt hàng chậm theo — độ khả dụng của ta bị xích vào bên thứ ba. Thread/worker pool của web app cạn vào giờ peak vì bị chiếm bởi các request “treo chờ bên ngoài” → cả những endpoint nhanh cũng chờ (Little’s Law, chương 1.3). 2. Vì sao kiến trúc cũ không còn phù hợp? Kiến trúc cũ trộn hai loại công việc có bản chất khác nhau vào một đường xử lý: ...

1. Vấn đề gì xuất hiện? VietShop đạt ~50K user, chạy quảng cáo tối. Triệu chứng đo được: DB CPU 85% vào 20–22h; p99 trang chủ từ 200ms lên 2.5s đúng khung giờ đó. pg_stat_statements chỉ mặt: 70% thời gian DB dành cho ~20 query đọc lặp lại — trang chủ, danh mục, top sản phẩm — kết quả gần như không đổi giữa hai lần chạy liên tiếp. Tỷ lệ đọc:ghi đo được ~60:1. 2. Vì sao kiến trúc cũ không còn phù hợp? DB đang tính lại hàng nghìn lần mỗi phút một kết quả không đổi. Vấn đề không phải PostgreSQL yếu — vấn đề là dùng công cụ đắt (query engine + disk) cho việc rẻ (nhớ lại một kết quả đã biết). Scale-up DB mua thêm thời gian nhưng đốt tiền vào đúng sự lãng phí đó; thêm read replica cũng vậy (nhân bản sự lãng phí ra N máy). First principles: dữ liệu đọc nhiều-ghi ít-chịu được trễ vài giây thuộc về RAM, nơi truy cập rẻ hơn disk 3 bậc độ lớn. ...

Bối cảnh VietShop ngày 0: 3 founder (2 dev), vốn đủ sống 12 tháng, mục tiêu ra thị trường trong 2 tháng. FR: đăng ký/đăng nhập, danh mục sản phẩm, giỏ hàng, đặt hàng COD, quản trị đơn giản. NFR thật sự chỉ có hai: ra tính năng nhanh và không mất dữ liệu đơn hàng. 1. Vấn đề cần giải Không phải scale — là tồn tại. Xác suất sản phẩm chết vì không có user cao gấp trăm lần chết vì quá nhiều user. Kiến trúc phù hợp là kiến trúc tối đa hóa tốc độ học từ thị trường trên mỗi đồng vốn. ...

Chương quan trọng nhất của tài liệu. Mọi khái niệm ở các phần trước được đặt vào một câu chuyện duy nhất, kể từ đầu đến cuối. Hệ thống xuyên suốt: sàn E-commerce “VietShop” Chúng ta theo chân một sàn thương mại điện tử Việt Nam từ ngày đầu tiên đến khi phục vụ hàng chục triệu người dùng. Chọn e-commerce vì nó chứa đủ các bài toán kinh điển: read-heavy (duyệt sản phẩm), tranh chấp ghi (tồn kho), tiền bạc (không được sai), spike cực đoan (flash sale), tác vụ nền (email, ảnh), tìm kiếm, và báo cáo. ...

1. Problem Statement Internet là môi trường thù địch mặc định: bot chiếm phần lớn traffic của nhiều site, credential stuffing chạy 24/7, scraper hút catalog, và thi thoảng một chiến dịch DDoS thật sự. Nếu mỗi service tự xử lý các mối lo này, ta có N bản cài đặt lệch nhau của cùng các phòng thủ (11.1 §2 — cùng lý do tập trung AuthN). Biên (edge) tồn tại để gom các mối quan tâm cắt ngang về một tuyến phòng thủ có tầng — để service phía sau tập trung vào nghiệp vụ, và để “một chỗ vá” khi có chuyện. ...

1. Problem Statement Ba bài toán token của mọi hệ hiện đại: app bên thứ ba cần truy cập dữ liệu user mà không cầm mật khẩu của user (ủy quyền — OAuth2); nhiều ứng dụng cần cùng một đăng nhập (SSO — OIDC); và N service cần xác minh danh tính người gọi mà không gọi về trung tâm mỗi request (token tự xác minh — JWT). Ba bài, một họ chuẩn — và một bãi mìn thuật ngữ nơi “dùng JWT” và “dùng OAuth” bị nói như thể là quyết định một chữ, trong khi mỗi lựa chọn con bên trong (flow nào, token sống bao lâu, thu hồi thế nào) mới là nơi an toàn được quyết định. ...