Distributed Systems

← Chương trước: Chương 2 — 3 Điểm Yếu Của Caching | Mục lục Series | Chương tiếp theo: Chương 4 — Transactional Outbox Pattern → Answer-first: Local rate limiters trên RAM cục bộ thất bại trong Microservices do tải bị chia đều qua nhiều nodes. Sử dụng trạng thái tập trung trên Redis với thuật toán GCRA (Generic Cell Rate Algorithm) thực thi qua các đoạn mã Atomic Lua scripts giúp kiểm soát lưu lượng chính xác tuyệt đối mà chỉ tốn đúng 1 key. ...

← Chương trước: Phần 5: Sharded MySQL vs. TiDB | Mục lục Series | Chương tiếp theo: Phần 7: Modular Monolith vs. Microservices vs. SpinKube Wasm → Apache Kafka (KRaft) vs. NATS JetStream: Đối Đầu Kiến Trúc Event Streaming Answer-first: Apache Kafka (KRaft) thống trị về thông lượng hàng triệu msg/sec và lưu trữ sự kiện dài hạn cho Data Lake/CDC nhưng gánh chi phí RAM lớn. NATS JetStream vượt trội với độ trễ P99 sub-1ms, tiêu thụ bộ nhớ siêu nhẹ (<50MB RAM) và cơ chế Stream Raft nhúng lý tưởng cho microservices và AI Agents. ...

← Chương trước: Khóa Phân Tán (Distributed Locks) — Toán Học Redlock, etcd Raft & Chống Chia Cắt Mạng | Mục lục Series | Chương tiếp theo: Mẫu Saga & Giao Dịch Phân Tán (Distributed Transactions) — Temporal, Outbox & Debezium → Answer-first: Thiết kế API kháng lặp (Idempotent API) sử dụng Idempotency-Key kết hợp Redis SetNX và Response Recorder middleware trong Go. Kiểm tra băm SHA-256 payload ngăn ngừa tái sử dụng khóa trái phép và đảm bảo kết quả thanh toán an toàn tuyệt đối khi client retry. ...

← Chương trước: Phần 7: Streaming Fraud Detection với Flink | Mục lục Series Answer-first: Cẩm nang SDET cho Core Banking thiết lập 6 nhóm kiểm thử chuyên sâu: kiểm thử Double-Spend, rách não mạng (Split-Brain), lệch đồng hồ vật lý, bù trừ Saga thất bại, rò rỉ token FAPI và mô phỏng dòng sự kiện Flink TestHarness nhằm đảm bảo 100% an toàn tài chính. Tại Sao Core Banking Cần SDET Riêng? Kiểm thử hệ thống tài chính phân tán đòi hỏi kỹ năng chuyên biệt ngoài unit tests thông thường. Các lỗi nghiêm trọng nhất thường chỉ xuất hiện khi có concurrency cao, network failures, clock drift, hoặc partial system failures — những điều kiện không thể reproduce bằng integration tests đơn giản. ...

Tech Radar: Deterministic Concurrency Testing with Go 1.25 testing/synctest Answer-First: The testing/synctest package in Go 1.25/1.26 eliminates flaky concurrency tests by isolating goroutines inside an event-driven “concurrency bubble” governed by a synthetic time clock. Virtual time advances instantaneously the moment all goroutines in the bubble are durably blocked, reproducing multi-step race conditions, backoff retries, and network timeouts in 2ms instead of waiting for 5–10s real-world time.Sleep() delays. 1. The Core Dilemma of Concurrency Testing: The time.Sleep Anti-Pattern In high-throughput Go microservices (Kafka stream consumers, Dapr actor sagas, gRPC retry circuits, distributed rate-limiters), testing timeouts, backoff strategies, and race conditions has historically suffered from flaky test instability. ...

High-throughput local LLM architecture guide combining vLLM PagedAttention virtual memory, Prefill-Decode disaggregation over RoCE v2/NVLink, and a custom Go API Gateway with SHA256 prompt prefix context-affinity routing, zero-allocation SSE streaming, and 71% cost savings over SaaS APIs.

Answer-first: Dapr State Store cung cấp sự đánh đổi linh hoạt giữa Strong và Eventual Consistency thông qua trừu tượng hóa component. Kết hợp ETag cho Optimistic Concurrency Control (OCC) cùng Redis hoặc CockroachDB giúp lập trình viên cân bằng chính xác giữa độ trễ cực thấp và tính toàn vẹn giao dịch ACID phân tán. 🇬🇧 Read the English version of this article on tanhdev.com Giới thiệu về Dapr State Management Trong phát triển ứng dụng phân tán hiện đại, quản lý trạng thái (state management) luôn là một trong những thử thách phức tạp nhất. Khi chuyển dịch sang kiến trúc microservices, mỗi dịch vụ thường yêu cầu lưu trữ và truy vấn dữ liệu một cách độc lập. Điều này dẫn đến sự phân mảnh công nghệ khi một hệ thống có thể sử dụng đồng thời Redis để làm cache, PostgreSQL để lưu trữ dữ liệu giao dịch, và Cassandra cho dữ liệu phi cấu trúc lớn. Dapr (Distributed Application Runtime) ra đời nhằm giải quyết vấn đề này thông qua cơ chế trừu tượng hóa (abstraction). ...

Answer-first: Alipay xử lý 583.000 TPS tại đỉnh điểm Double 11 nhờ kiến trúc LDC (Logical Data Center) Unitization 5 Trung tâm 3 Vùng (5DC-3Region). Hệ thống kết hợp cơ sở dữ liệu phân tán OceanBase Paxos consensus, bộ đệm đa tầng CTU chống nghẽn và luồng bù trừ thanh toán phi tập trung, đạt RPO=0 và RTO<30s. 🇬🇧 Read the English version of this article on tanhdev.com Vào lúc nửa đêm ngày 11 tháng 11, khoảng 1,5 tỷ người trên khắp châu Á đồng loạt mở một ứng dụng duy nhất và bắt đầu chạm vào “Mua ngay”. Trong 60 giây đầu tiên, Alipay xử lý nhiều giao dịch hơn một ngân hàng lớn ở phương Tây xử lý trong cả một ngày. Đỉnh điểm của Ngày Lễ Độc Thân (Singles’ Day) năm 2023 — 583.000 giao dịch thanh toán mỗi giây (TPS) — không chỉ là một tiêu đề báo. Đó là sản phẩm của mười bốn năm tiến hóa kiến trúc đã định nghĩa lại ý nghĩa của từ “sẵn sàng cho production” đối với một nền tảng tài chính. ...