Làm Chủ Hệ Thống High-Concurrency Trên Môi Trường Production

Phiên bản Song ngữ Quốc tế: 📖 Bản tiếng Anh (English Edition) | Masterclass này được phát hành song song bằng tiếng Anh tại High Concurrency Systems Masterclass (tanhdev.com).

1. Tổng Quan Series: Masterclass High-Concurrency

Khi hệ thống của bạn tăng trưởng từ hàng chục ngàn lên hàng triệu người dùng hoạt động đồng thời (C10M), các giải pháp mở rộng thông thường như tăng RAM/CPU hay thêm replica database sẽ nhanh chóng chạm ngưỡng giới hạn vật lý. Các thảm họa phổ biến như Cache Breakdown, Dual-Write Inconsistency, Connection Pool Exhaustion và Distributed Deadlocks sẽ đánh sập toàn bộ dịch vụ trong tích tắc.

Series này được đúc kết từ 17+ năm kinh nghiệm thực chiến thiết kế kiến trúc chịu tải cho các nền tảng thương mại điện tử quy mô lớn tại Đông Nam Á, cung cấp các blueprint và mã nguồn Golang chuẩn mực nhất.

flowchart TD
    subgraph ClientTier ["Lớp Client & Edge Ingress"]
        C["Hàng triệu Clients (Web / Mobile)"] --> Anycast["Anycast Edge & Anti-DDoS"]
        Anycast --> L4["L4 Load Balancer (DPDK / eBPF XDP)"]
        L4 --> L7["L7 API Gateway (Envoy / K8s Gateway API)"]
    end

    subgraph ServiceMesh ["Cụm Go Microservices & Runtime"]
        L7 --> Svc1["Order Service (M:N Netpoller)"]
        L7 --> Svc2["Payment Service (Idempotency Engine)"]
        Svc1 <--> L1Cache["L1 Memory Cache (BigCache Off-Heap)"]
    end

    subgraph DataMesh ["Lớp Lưu Trữ Phân Tán & Event Streaming"]
        Svc1 --> L2Cache["L2 Distributed Cache (Redis 7.4 Cluster)"]
        Svc1 --> Pooler["Connection Multiplexer (PgBouncer / Pgcat)"]
        Pooler --> PrimaryDB["PostgreSQL Primary (ACID Master)"]
        PrimaryDB --> Replicas["PostgreSQL Replicas (Read/Write Split)"]
        PrimaryDB --> CDC["Change Data Capture (Debezium / WAL)"]
        CDC --> Kafka["Kafka Event Mesh (Transactional Outbox)"]
    end

    classDef edge fill:#e1f5fe,stroke:#0288d1,stroke-width:2px;
    classDef svc fill:#e8f5e9,stroke:#388e3c,stroke-width:2px;
    classDef data fill:#fff3e0,stroke:#f57c00,stroke-width:2px;
    class ClientTier edge;
    class ServiceMesh svc;
    class DataMesh data;

2. Lộ Trình 10 Chương Học Thực Chiến

Toàn bộ Masterclass được cấu trúc thành mười chương chuyên sâu, bao quát toàn bộ vòng đời của một giao dịch có độ trễ cực thấp:

flowchart LR
    P0["Chương 0: C10M Realities<br/>(Tóm Tắt Lãnh Đạo)"] --> P1["Chương 1: Kernel I/O<br/>(io_uring & Netpoller)"]
    P1 --> P2["Chương 2: Cache Defenses<br/>(Singleflight & Bloom)"]
    P2 --> P3["Chương 3: Rate Limiting<br/>(GCRA & Redis Lua)"]
    P3 --> P4["Chương 4: Dual-Write<br/>(Transactional Outbox)"]
    P4 --> P5["Chương 5: DB Pools<br/>(PgBouncer & Tối Ưu)"]
    P5 --> P6["Chương 6: Ingress vs Mesh<br/>(Gateway vs Service Mesh)"]
    P6 --> P7["Chương 7: Idempotency<br/>(APIs Thanh Toán)"]
    P7 --> P8["Chương 8: Distributed Lock<br/>(Redlock vs ZooKeeper)"]
    P8 --> P9["Chương 9: DB Sharding<br/>(Vitess & Hashing)"]

    classDef flow fill:#ede7f6,stroke:#512da8,stroke-width:2px;
    class P0,P1,P2,P3,P4,P5,P6,P7,P8,P9 flow;

Chi Tiết Nội Dung Từng Chương

0. Chương 0: Thực Tế Của C10M: Sống Sót Qua Lưu Lượng Khổng Lồ — Tóm Tắt Dành Cho Lãnh Đạo

• Thách thức cốt lõi: Mở rộng phần cứng theo chiều dọc (Vertical Scaling) nhanh chóng chạm trần hiệu quả kinh tế khi số lượng socket kết nối vượt ngưỡng 100,000 kết nối hoạt động.
• Giải pháp kiến trúc: Chuyển đổi sang mô hình xử lý bất đồng bộ non-blocking hướng sự kiện, cấp phát bộ nhớ lock-free và cơ chế bỏ qua kernel (Kernel Bypass).
• Thu hoạch then chốt: Thấu hiểu bản chất toán học của việc quản lý trạng thái đồng thời, giới hạn bus bộ nhớ phần cứng và chi phí chuyển đổi ngữ cảnh CPU thread.

1. Chương 1: Các Hệ Thống Xử Lý Hàng Triệu Requests/s (C10M) Ra Sao? Bài Học Từ Shopee & Alipay

• Thách thức cốt lõi: Chi phí chuyển đổi ngữ cảnh (Context Switching) và xử lý ngắt phần cứng (Hardware Interrupts) của Linux kernel làm sụt giảm thông lượng nghiêm trọng dưới mật độ kết nối C10M.
• Giải pháp kiến trúc: Đi sâu vào Linux epoll, vòng đệm bất đồng bộ io_uring, bộ điều khiển user-space DPDK và bộ lập lịch M:N Go Runtime Netpoller.
• Thu hoạch then chốt: Triệt tiêu tổn thất context switch của hệ điều hành, cấu hình bộ đệm socket zero-copy và làm chủ memory pooling trên Go 1.25+ để tránh dừng GC.

2. Chương 2: 3 Điểm Yếu Của Caching (Penetration, Breakdown, Avalanche) & Kỹ Thuật Go Singleflight

• Thách thức cốt lõi: Cache Penetration (truy vấn key rác), Cache Breakdown (hot key hết hạn) và Cache Avalanche (hàng loạt key hết hạn cùng lúc) gây ra sập cơ sở dữ liệu hàng loạt.
• Giải pháp kiến trúc: Phòng thủ đa tầng kết hợp Counting Bloom Filter, thuật toán tính xác suất hết hạn sớm XFetch, làm rung lắc thời gian sống TTL (Jittering) và thư viện Go singleflight.Group.
• Thu hoạch then chốt: Đảm bảo hàng chục ngàn truy vấn trượt cache đồng thời được gom lại thành đúng duy nhất một truy vấn tới database gốc.

3. Chương 3: Distributed Rate Limiting Với Redis & Thuật Toán GCRA

• Thách thức cốt lõi: Thuật toán Token Bucket và Sliding Window truyền thống gây bùng nổ bộ nhớ và lỗi bùng phát lưu lượng tại biên giới hạn trong kiến trúc Microservices phân tán.
• Giải pháp kiến trúc: Thuật toán Generic Cell Rate Algorithm (GCRA) triển khai qua Redis Lua Script nguyên tử với việc theo dõi thời điểm đến lý thuyết tiếp theo (Theoretical Arrival Time - TAT).
• Thu hoạch then chốt: Thực thi giới hạn tốc độ dưới mili-giây với zero race condition, giới hạn dung lượng bộ nhớ chỉ 64 bytes cho mỗi định danh được theo dõi.

4. Chương 4: Gỡ Rối Bài Toán Dual-Write Với Transactional Outbox Pattern

• Thách thức cốt lõi: Thao tác ghi cơ sở dữ liệu đồng thời với việc gửi tin nhắn tới Kafka trong mã nguồn ứng dụng tất yếu dẫn đến lệch dữ liệu khi mạng gặp sự cố.
• Giải pháp kiến trúc: Transactional Outbox Pattern kết hợp transaction ACID cục bộ của cơ sở dữ liệu với giải pháp Change Data Capture (CDC Debezium) và kiểm tra tính lũy kế ở consumer.
• Thu hoạch then chốt: Đảm bảo ngữ nghĩa chuyển giao tin nhắn ít nhất một lần (At-Least-Once) tới event mesh phân tán mà không cần khóa phân tán hay quét bảng định kỳ.

5. Chương 5: Tối Ưu Connection Pools Của Database Trong Golang Để Ngăn Chặn Thắt Cổ Chai

• Thách thức cốt lõi: Quản lý pool kết nối *sql.DB thiếu chặt chẽ làm cạn kiệt năng lực tiến trình của PostgreSQL, trong khi cấu hình idle bất đối xứng gây bão bắt tay TCP liên tục.
• Giải pháp kiến trúc: Áp dụng Định luật Little ($L = \lambda W$) để tính toán kích thước pool khoa học, cấu hình pool đối xứng hoàn toàn và gom socket qua PgBouncer hoặc Pgcat.
• Thu hoạch then chốt: Giảm 22% CPU của database, triệt tiêu lỗi ngắt kết nối ngầm 350 giây của AWS NAT Gateway, ghép 25,000 socket client vào 60 kết nối thực tế.

6. Chương 6: API Gateway Đấu Với Service Mesh Trong Kiến Trúc Microservices

• Thách thức cốt lõi: Mô hình Service Mesh truyền thống tiêm Sidecar proxy gây độ trễ nặng nề và lãng phí tài nguyên bộ nhớ trên chuỗi gọi RPC phân tầng.
• Giải pháp kiến trúc: Kubernetes Gateway API kết hợp Envoy cho lưu lượng North-South và mô hình Sidecarless Istio Ambient cùng Cilium eBPF sockops cho lưu lượng East-West.
• Thu hoạch then chốt: Bỏ qua 4 lần duyệt TCP stack của kernel, giảm độ trễ giữa các pod từ 1.8ms xuống 40 micro-giây trong khi vẫn áp dụng mTLS zero-trust SPIFFE/SPIRE.

7. Chương 7: Thiết Kế Idempotency APIs Dành Cho Hệ Thống Thanh Toán

• Thách thức cốt lõi: Mạng bị ngắt quãng và bão retry trong API thanh toán kích hoạt thảm họa trừ tiền hai lần và tổn thất tài chính nghiêm trọng.
• Giải pháp kiến trúc: Chuẩn hóa header IETF Idempotency-Key, máy trạng thái hữu hạn 3 pha, băm dấu vân tay request bằng SHA-256 và ràng buộc UNIQUE ở tầng SQL.
• Thu hoạch then chốt: Xây dựng cổng thanh toán an toàn tuyệt đối trước rớt mạng, từ chối sửa đổi payload bất hợp lệ (HTTP 422) và loại bỏ 100% rủi ro trừ tiền trùng lặp.

8. Chương 8: Distributed Locking Xử Lý Tranh Chấp Race Conditions: Redlock Đấu Với ZooKeeper

• Thách thức cốt lõi: Hiện tượng tạm dừng Garbage Collection Stop-The-World, nhảy giờ hệ thống NTP và độ trễ mạng phá vỡ tính loại trừ tương hỗ trong Redlock.
• Giải pháp kiến trúc: Phân tích sâu tranh luận Kleppmann-Antirez, triển khai Monotonic Fencing Token và cơ chế Preceding Node Watcher trên Apache ZooKeeper hoặc etcd Raft Lease.
• Thu hoạch then chốt: Phân biệt khóa hiệu năng (Efficiency) với khóa tính đúng (Correctness), triệt tiêu bão Thundering Herd và xác thực token tăng dần tại kho lưu trữ.

9. Chương 9: Database Sharding & Read/Write Splitting Dành Cho Các Bảng Dữ Liệu Hàng Tỷ Bản Ghi

• Thách thức cốt lõi: Cơ sở dữ liệu quan hệ chạm trần IOPS ghi và phình to bộ đệm chỉ mục B-Tree, trong khi replica đọc gặp dị biệt do độ trễ sao chép (Replication Lag).
• Giải pháp kiến trúc: Phân tách Đọc/Ghi gắn phiên (Session Pinning), phân mảnh nhất quán với nút ảo (Virtual Nodes Consistent Hashing), định danh Snowflake 64-bit và chia tách trực tiếp không downtime.
• Thu hoạch then chốt: Mở rộng cơ sở dữ liệu theo chiều ngang đạt hơn 100,000 lượt ghi mỗi giây không gián đoạn dịch vụ, triệt tiêu phân tách trang B-Tree và thảm họa chia dư modulo N.

3. Cơ Chế Lan Truyền Thất Bại & Hệ Thống Phòng Thủ Đa Tầng

Trong các đợt bùng nổ chiến dịch mua sắm, sự cố cục bộ tại một thành phần nhỏ có thể nhanh chóng trở thành thảm họa sập toàn bộ hệ thống thông qua vòng lặp phản hồi dương (Positive Feedback Loop):

sequenceDiagram
    autonumber
    participant Client as Khách Hàng (Bão Lưu Lượng)
    participant Gateway as API Gateway
    participant Svc as Go Order Pods
    participant Cache as Redis Cache
    participant DB as PostgreSQL Primary Master

    Client->>Gateway: Lưu Lượng Tăng Đột Biến (Gấp 10 Lần)
    Gateway->>Svc: Điều Phối 50,000 RPS
    Svc->>Cache: Hot Cache Key Hết Hạn! (Cache Breakdown)
    Note over Svc,DB: 50,000 Goroutines Cùng Trượt Cache!
    Svc->>DB: Bão Kết Nối Trực Tiếp (50,000 Sockets)
    DB->>DB: CPU PostgreSQL Chạm 100% (Tranh Chấp Khóa ProcArrayLock)
    DB-->>Svc: Độ Trễ Truy Vấn Bùng Nổ (Từ 2ms Vọt Lên 15,000ms)
    Svc->>Svc: Cạn Kiệt Goroutine Pool & Bộ Nhớ Phình To
    Gateway--xSvc: Kiểm Tra Sức Khỏe Lỗi -> Pods CrashLoopBackOff!
    Gateway-->>Client: HTTP 503 Dịch Vụ Không Khả Dụng (Sập Hệ Thống!)

Năm Trụ Cột Phòng Thủ Bất Biến

Để chặn đứng sự cố dây chuyền, kiến trúc Masterclass đặt ra 5 nguyên tắc bắt buộc:

1. Kiểm Soát Nhập Cuộc Xác Định (Admission Control): Giới hạn tốc độ và chủ động ngắt tải ngay tại biên mạng (Chương 3) trước khi lưu lượng chưa xác thực tiến sâu vào hệ thống compute.
2. Gộp Đọc Bộ Nhớ Đệm Đa Luồng (Coalesced Singleflight): Áp dụng singleflight.Group (Chương 2) để hàng ngàn truy vấn trượt cache đồng thời được gộp lại thành một lệnh duy nhất.
3. Giới Hạn Socket Bằng Connection Pooler: Ghép toàn bộ kết nối ứng dụng qua các bộ tập trung kết nối như PgBouncer (Chương 5) dựa trên Định luật Little.
4. Tách Rời Bất Đồng Bộ Qua Transactional Outbox: Loại bỏ hoàn toàn các cuộc gọi RPC ghi phân tán giữa các dịch vụ bằng cách stream log CDC từ bảng outbox (Chương 4).
5. Khóa Fencing Token Đơn Điệu: Từ chối mọi thao tác ghi muộn tại tầng lưu trữ dữ liệu bằng cách đối chiếu token fencing tăng dần đều (Chương 8).

4. Bảng Ma Trận Công Nghệ & Tiêu Chuẩn SOTA 2027

Bảng tổng hợp dưới đây đối chiếu giữa phương pháp truyền thống và chuẩn mực kiến trúc 2027 được phân tích trong series:

5. Mô Hình Tính Toán Năng Lực Phần Cứng & Định Luật Hàng Đợi

Để vận hành ổn định 25 triệu giao dịch mỗi tháng với hệ số tải đỉnh gấp 15 lần ngày thường, kiến trúc sư trưởng cần tính toán dựa trên các mô hình toán học định lượng:

1. Ứng Dụng Định Luật Little Cho Database Connection Pool

Theo Định luật Little ($L = \lambda \cdot W$):

• Cường độ truy vấn đỉnh ($\lambda$): Trong đợt bùng nổ chiến dịch với 30,000 request/giây trên toàn cụm microservices, số lượng truy vấn database đạt $\lambda = 15,000\text{ QPS}$.
• Thời gian xử lý trung bình ($W$): Các truy vấn đọc có chỉ mục tối ưu hoàn tất trong $W = 0.002\text{ giây}$ (2 mili-giây).
• Số kết nối vật lý đồng thời tối ưu ($L$): $$L = 15,000 \times 0.002 = 30\text{ kết nối đồng thời}$$ Nếu cấu hình sai lầm bằng cách cấp 200 kết nối cho mỗi pod trong 50 pod, tổng số kết nối vật lý lên tới 10,000. PostgreSQL sẽ bị tê liệt do tranh chấp khóa nội bộ ProcArrayLock, giảm 80% thông lượng. Việc đặt PgBouncer ở giữa với pool vật lý $L = 60$ (đã cộng biên độ an toàn) giúp database hoạt động ở đỉnh hiệu năng.

2. Tối Ưu Bộ Nhớ Redis: GCRA So Với Sliding Window Counter

Khi quản lý hạn mức truy cập cho 5,000,000 tài khoản người bán:

• Sliding Window Log: Lưu các timestamp trong Sorted Set (ZADD) với giới hạn 100 request/phút tiêu tốn: $$\text{Dung lượng} = 5,000,000 \times 100 \times (8\text{ B timestamp} + 8\text{ B member} + 48\text{ B jemalloc}) \approx 32\text{ GB RAM}$$
• Generic Cell Rate Algorithm (GCRA): Lưu đúng một số nguyên 64-bit đại diện cho thời điểm phát sinh lý thuyết (TAT) trong một key đơn giản: $$\text{Dung lượng} = 5,000,000 \times (8\text{ B TAT} + 48\text{ B header object}) \approx 280\text{ MB RAM}$$ GCRA giúp tiết kiệm 114 lần dung lượng RAM, cho phép toàn bộ trạng thái giới hạn tốc độ nằm gọn trong L3 cache và RAM của Redis server.

3. Tinh Chỉnh Socket Buffer & Thông Số Mạng Linux Kernel

Đối với các Go service chịu tải trên 100,000 kết nối đồng thời:

• Thiết lập net.core.somaxconn = 65535 và net.ipv4.tcp_max_syn_backlog = 65535 để loại trừ hiện tượng drop gói tin SYN khi bão kết nối ập tới.
• Tinh chỉnh net.ipv4.tcp_rmem = 4096 87380 16777216 và net.ipv4.tcp_wmem = 4096 65536 16777216 để hệ điều hành linh hoạt cấp phát buffer theo kích thước gói tin nhưng vẫn kiểm soát tổng giới hạn qua net.ipv4.tcp_mem.

6. Năm Nguyên Tắc Bất Biến Của Hệ Thống Chịu Tải Cao

Mỗi chương trong Masterclass đều tuân thủ nghiêm ngặt 5 nguyên tắc bất biến:

1. Nguyên Tắc Ranh Giới Giao Dịch Đơn: Không bao giờ gọi mạng ra bên ngoài (HTTP, gRPC, Kafka, Redis) bên trong một transaction của cơ sở dữ liệu quan hệ. Biến động trạng thái và bản ghi outbox phải được commit nguyên tử trong cùng một ACID transaction cục bộ.
2. Nguyên Tắc Kích Thước Pool Đối Xứng: Luôn cấu hình SetMaxIdleConns bằng đúng SetMaxOpenConns trong database/sql của Golang. Việc để pool idle thu hẹp sẽ tạo ra chu kỳ hủy và tạo mới kết nối TCP liên tục cùng nguy cơ timeout ngầm trên AWS NAT Gateway.
3. Nguyên Tắc Fencing Token Tăng Đơn Điệu: Không bao giờ tin tưởng thời hạn thuê (lease duration) của khóa phân tán khi có phân mảnh mạng hoặc GC Stop-The-World. Mọi lệnh ghi trạng thái xuống database bắt buộc phải kiểm tra token fencing tăng dần đều.
4. Nguyên Tắc Gộp Đọc Singleflight: Tuyệt đối không cho phép nhiều goroutine cùng lúc truy vấn một key bị miss xuống cơ sở dữ liệu gốc. Bắt buộc gom nhóm qua cơ chế singleflight để chỉ phát sinh đúng một truy vấn vật lý.
5. Nguyên Tắc Bỏ Qua Không Gian Kernel (Zero Kernel-Space): Triệt tiêu chi phí trung gian của các proxy user-space đối với các luồng giao tiếp nội bộ tần suất cao bằng việc ứng dụng kỹ thuật eBPF sockops.

7. Các Nghiên Cứu Điển Hình Thực Tế (Case Studies)

Các giải pháp trong Masterclass này đã được kiểm chứng thực tế tại các nền tảng thương mại điện tử và công nghệ tài chính quy mô hàng đầu:

• Đại Hội Mua Sắm Alipay Double 11: Chịu tải 610,000 giao dịch thanh toán mỗi giây nhờ công cụ trạng thái lũy kế, kỹ thuật ghim số dư vào bộ nhớ và đồng thuận phân tán xuyên trung tâm dữ liệu.
• Chiến Dịch Siêu Sale Shopee Đông Nam Á: Phân bổ tồn kho flash-sale an toàn bằng bộ giới hạn tốc độ phân tán Redis GCRA và đường truyền sự kiện Transactional Outbox bất đồng bộ.
• Hệ Thống Ngân Hàng Số Cốt Lõi (Core Banking): Đảm bảo giao dịch tài chính tuyệt đối không thất thoát bằng cách kết hợp header chuẩn IETF Idempotency-Key và loại bỏ 2-Phase Commit bằng Saga Orchestration.

8. Câu Hỏi Thường Gặp (FAQ)

9. Danh Sách Kiểm Tra Sẵn Sàng Triển Khai Production

Trước khi cấp phép cho hệ thống phân tán chịu tải cao vận hành trên môi trường live production, đội ngũ Platform Engineering cần hoàn tất bảng kiểm toán sau:

1. Tầng Ingress & Điều Phối Lưu Lượng

• Tài nguyên Kubernetes Gateway API HTTPRoute được cấu hình đầy đủ timeout và circuit breaker phát hiện outlier.
• Giới hạn tốc độ phân tán hoạt động qua Redis GCRA Lua scripts, áp dụng hạn ngạch phân tầng cho từng đối tác.
• Luật phòng thủ DDoS và WAF được kích hoạt tại tầng Anycast Edge Network.

2. Tầng Runtime & Ứng Dụng Go

• Cấu hình Go runtime với biến môi trường GOMAXPROCS khớp chính xác giới hạn CPU của Kubernetes container.
• Tất cả các truy vấn cơ sở dữ liệu đều được bao bọc bởi context.WithTimeout rõ ràng.
• Không có đối tượng *sql.Rows nào bị bỏ quên đóng, được xác minh bằng công cụ kiểm tra tĩnh sqlclosecheck trong CI/CD.
• Header chuẩn W3C traceparent được truyền dẫn xuyên suốt các cuộc gọi nội bộ HTTP và gRPC.

3. Tầng Cơ Sở Dữ Liệu & Bộ Nhớ Đệm

• Đối tượng *sql.DB trong Go được cấu hình đối xứng: SetMaxIdleConns == SetMaxOpenConns.
• Tham số SetConnMaxLifetime được đặt dưới 300 giây kèm độ rung (jitter) để tránh lỗi ngắt kết nối ngầm 350 giây của AWS NAT Gateway.
• Cụm PgBouncer hoặc Pgcat hoạt động ở chế độ Transaction Pooling phía trước PostgreSQL.
• Mẫu Transactional Outbox được triển khai với Debezium CDC đẩy sự kiện sang Apache Kafka.
• Ràng buộc UNIQUE ở tầng SQL được áp dụng cho mọi khóa lũy kế và khóa giao dịch tài chính.

4. Tầng Quan Sát & Kiểm Thử Hỗn Loạn (Chaos Engineering)

• Cảnh báo Prometheus được thiết lập cho go_sql_db_wait_duration_seconds_total và go_sql_db_wait_count_total.
• Traces phân tán được gửi về OpenTelemetry Collector với cơ chế lấy mẫu 100% trên các luồng có lỗi (Error Tail-Sampling).
• Thực thi diễn tập hỗn loạn: kiểm chứng hệ thống tự phục hồi khi có độ trễ mạng giả lập, kill pod ngẫu nhiên và failover node Redis.

10. Liên Kết Series Chuyên Sâu

• Kiến Trúc Core Banking Phân Tán: Áp dụng Idempotency, Transactional Outbox và Distributed SQL vào hệ thống thanh toán ngân hàng.
• Kiến Trúc Real-time Ứng Dụng Gọi Xe: Xử lý luồng sự kiện streaming hàng triệu sự kiện/giây với Kafka & Flink.
• Modular Monolith Architecture: Tối ưu hóa kiến trúc ứng dụng liền khối hiệu năng cao trước khi tách microservices.
• Kiến Trúc Hệ Thống Shopee: Chiến lược chịu tải khổng lồ trong các sự kiện Mega Sale TMĐT Đông Nam Á.