Kafka

Trong Phần 1: The Paradigm Shift - Kiến Trúc Agentic & Sức Mạnh Điều Phối Của Golang, chúng ta đã thiết lập bộ não điều phối (Orchestration Engine) bằng Golang và Eino. Tuy nhiên, một bộ não thông minh đến đâu cũng sẽ trở nên vô dụng nếu nó được tiếp nạp thông tin sai lệch, thiếu cấu trúc hoặc bị cắt vụn. Trong bài toán e-commerce, dữ liệu catalog sản phẩm thay đổi liên tục từng giây: giá cả biến động, tồn kho cập nhật, sản phẩm mới được thêm vào. Đồng thời, việc chia nhỏ (chunking) dữ liệu sản phẩm để đưa vào Vector Database (Qdrant) hoàn toàn khác biệt so với việc chia nhỏ một tài liệu PDF hay một bài báo. ...

1. “Dữ Liệu Ngày Hôm Qua” Là Một Thảm Họa Nếu một khách hàng hỏi Chatbot của ngân hàng về lãi suất tiết kiệm, và Chatbot trả lời dựa trên File PDF chính sách đã bị thay đổi từ… 2 tiếng trước. Điều gì sẽ xảy ra? Trong các môi trường Enterprise như Tài chính, Y tế hay E-commerce, Dữ liệu của ngày hôm qua là một khoản nợ pháp lý. Các đường ống dữ liệu kiểu cũ (ETL Batch Jobs chạy lúc nửa đêm) đã không còn đáp ứng được yêu cầu của năm 2026. Nếu kho dữ liệu cốt lõi (Core Database) thay đổi, Vector Database của bạn phải được cập nhật ngay lập tức. Độ trễ (Data Freshness) phải được tính bằng giây. ...

🇬🇧 Read the English version of this article on tanhdev.com Answer-first: Khi chuyển đổi từ Magento sang Golang, bạn có ba chiến lược cơ sở dữ liệu (database): (A) Dùng chung DB (Shared DB) để tối ưu compute ngay lập tức, (B) CDC + Outbox để tách DB dần dần mà không cần đụng vào code PHP, hoặc (C) Tách biệt hoàn toàn bằng Event Bus. Phương án A là một trạng thái chuyển giao tuyệt vời nhưng lại là một trạng thái cuối cùng thảm họa. Phương án B là con đường được khuyến nghị trong ngành công nghiệp cho hầu hết các hệ thống Magento — nó cho phép Go làm chủ schema của riêng mình và làm phẳng cấu trúc EAV mà không yêu cầu PHP Magento phải phát ra dù chỉ một sự kiện nào. Phương án C chỉ khả thi khi đội ngũ Magento của bạn có thể xây dựng và duy trì một hệ thống phát hành sự kiện (event publisher) đáng tin cậy. ...

🇬🇧 Read the English version of this article on tanhdev.com Kiến trúc Ecommerce 2026: Vượt Qua Nợ Kỹ Thuật Khi Chuyển Đổi Sang Composable Commerce Trên lý thuyết, MACH (Microservices, API-first, Cloud-native, Headless) và Composable Commerce là “chén thánh” của ngành thương mại điện tử. Tuy nhiên, khi hệ thống đạt mốc xử lý hàng triệu giao dịch, những vấn đề về tính nhất quán dữ liệu và chi phí quan sát hệ thống (Observability) mới thực sự lộ diện. Bài viết này đúc kết kinh nghiệm xương máu từ đội ngũ kiến trúc sư trưởng (Chief Architect) khi đưa hệ thống từ Monolith lên Composable. ...

Điều kiện tiên quyết: Đây là Phần 5 của Khóa Học System Design. Quẹo lội lại Phần 4: Phình To Cơ Sở Dữ Liệu để thấu cái hang ổ lưu trữ (storage tier) nơi đám rác sự kiện lỳ lợm (persisted events) bị quăng xuống. Answer-first: Cấu Trúc Bám Đuôi Sự Kiện (Event-Driven Architecture) giật đứt tung mớ xiềng xích gò bó (decouples services) bằng cái luồng chửi thề chéo hông (asynchronous communication) qua một quyển sổ thù vặt trâu bò (durable message log). Ở xứ Go, mớ goroutines và ống xả có nắp (buffered channels) đẻ ra cái luồng nhịn nhục xả áp bẩm sinh (natural backpressure) — bao giờ tụi bóc rác (consumers) lết lếch lê gối hụt hơi nhặt không kịp đống rác của lũ vãi rác (producers), cái ống xả đầy ụ ứ họng sẽ tự bịt mõm (blocks) thằng xả rác, khóa hầu bao bóp họng dội ngược tốc độ ăn rác (throttling the ingest rate) một cách điêu luyện. ...

🇬🇧 Read the English version of this article on tanhdev.com Answer-first: Cách các ngân hàng thay thế core banking nguyên khối (Temenos, Finacle) bằng kiến trúc composable banking (ngân hàng cấu thành) thông qua việc sử dụng Go microservices, điều phối Saga (Saga orchestration), NewSQL ledgers và mô hình Strangler Fig. Các hệ thống core banking cũ (legacy) được thiết kế trong một thời đại khác. Temenos T24, Finacle và Flexcube đều chia sẻ một giả định chung mang tính quyết định: toàn bộ danh mục sản phẩm của ngân hàng — tiền gửi (deposits), cho vay (lending), thanh toán (payments), tài trợ thương mại (trade finance) — sẽ nằm bên trong một ứng dụng được liên kết chặt chẽ (tightly coupled) duy nhất và một database dùng chung duy nhất. Giả định đó có thể đúng khi ngành ngân hàng di chuyển với tốc độ của con người. Nhưng nó hoàn toàn sụp đổ khi các chu kỳ release (phát hành sản phẩm) cần phải rút ngắn từ vài tháng xuống vài ngày, khi việc cập nhật một engine chống gian lận (fraud engine) không được phép gây rủi ro ngừng hoạt động (outage) cho hệ thống thanh toán, và khi các kỹ sư đang làm việc trên nền codebase COBOL nghỉ hưu nhanh hơn tốc độ họ có thể được thay thế. ...

← Bài trước | Series hub | Tiếp theo → Chương 4: Xóa Sổ Cơn Ác Mộng Dual-Write Ngay khi ứng dụng Golang của bạn dịch chuyển từ Monolith (kiến trúc nguyên khối) sang mô hình Event-Driven Microservices, bạn sẽ lập tức nếm mùi một cơn ác mộng kiến trúc: Vấn Đề Dual-Write (Ghi song song). 1. Vấn Đề Dual-Write Là Gì? Answer-first: Dual-Write bộc phát lúc một ứng dụng thử cố gắng vừa lưu chép xuống Database vừa thả (publish) event tới Message Broker (Kafka) cùng một lúc. Do không có vỏ bọc của một transaction phân tán (distributed transaction), chỉ một lần vấp lỗi mạng cũng đủ sức khiến hai hệ thống trên rớt nhịp đồng bộ mãi mãi. ...

🇬🇧 Read the English version of this article on tanhdev.com Đồng Bộ Tồn Kho Thời Gian Thực Là Gì? Answer-first: Đồng bộ tồn kho thời gian thực (Real-time inventory synchronization) là quá trình lan truyền các thay đổi về số lượng hàng trong kho từ hệ thống gốc (database) tới tất cả các kênh bán hàng — web storefront, ứng dụng mobile, WMS, ERP — với độ trễ chưa tới một giây (sub-second). Thay vì phải phụ thuộc vào các tác vụ batch ETL chạy mỗi giờ, một pipeline CDC + Kafka sẽ stream mọi thay đổi tồn kho được commit thành một sự kiện (event), qua đó loại bỏ hoàn toàn tình trạng bán vượt mức (overselling) cũng như tránh hiển thị sai số lượng hàng hóa. ...

🇬🇧 Read the English version of this article on tanhdev.com Việc giám sát (Monitoring) các hệ thống Go microservices phức tạp đòi hỏi nhiều thứ hơn là chỉ các file logs độc lập riêng lẻ. Khi một request (yêu cầu) đi xuyên qua các HTTP APIs, luồng sự kiện (event streams) Kafka, và các worker pools bất đồng bộ (asynchronous worker pools), bạn cần một mức độ hiển thị tuyệt đối (absolute visibility) để có thể xác định chính xác các điểm nghẽn độ trễ (latency bottlenecks) cũng như các lỗi thất bại. ...

🇬🇧 Read the English version of this article on tanhdev.com Ngay cái giây bạn bật cái app Uber hay Grab lên, 1 thác hệ thống thời gian thực (real-time systems) ồ ạt nổ máy cùng 1 lúc: điện thoại của bạn lăm le nhả tọa độ GPS, cái bản đồ không gian (geospatial index) xào lại vị trí của bạn, 1 cỗ máy ghép kèo (matching engine) soi lại mớ tài xế đang rảnh rỗi quanh đó, 1 mô hình tính tiền (pricing model) rặn ra cái giá mới toanh dựa trên tỷ lệ giành giật (supply-demand ratios), và 1 cái ống phụt tin nhắn (push notification pipeline) lên nòng hòng bắn cái tin chốt kèo tới tay trong vòng dưới 3 giây. ...

🇬🇧 Read the English version of this article on tanhdev.com PayPay vừa bấm nút chạy hồi tháng 10 năm 2018 thì đã hốt trọn 10 triệu người dùng chỉ trong vỏn vẹn 3 tháng — cái đà phi mã mà chả có mống fintech Nhật Bản nào từng ngó thấy. Tới tận năm 2025, cái nền tảng này đã cán mốc 70 triệu user đăng ký và cày 7.8 tỷ lượt thanh toán mỗi năm. Chống lưng cho cú vọt mọc đó là 1 đội ngũ kỹ sư ứ những phải còng lưng bung rộng cái dàn hạ tầng của họ, mà còn phải xới tung cả cái văn hóa làm kỹ thuật: từ vụ ốp chuẩn dịch vụ (service standardization) và đẩy code kiểu GitOps (GitOps-driven deployments) cho tới trò chọc phá hệ thống (chaos engineering) và nhúng AI vô để túm bọn lừa đảo (fraud detection). ...

So Sánh Alipay Stack với Công Nghệ Hiện Đại Tổng Quan So Sánh Alipay Stack Modern Equivalent Key Difference LDC + RZone Kubernetes + Multi-cluster LDC: Business-driven sharding; K8s: Infrastructure abstraction OceanBase CockroachDB/TiDB/YugabyteDB OceanBase: 10+ years prod, custom FPGA; Newer: Cloud-native first RocketMQ Apache Kafka/Apache Pulsar RocketMQ: LSM-tree + rich msg types; Kafka: Log-centric; Pulsar: Tiered storage SOFARPC gRPC/Envoy Proxy SOFARPC: Java-centric, financial features; gRPC: Cross-platform, protobuf SOFAMesh (MOSN) Istio/Linkerd MOSN: Go-based, X-protocol; Istio: Envoy C++, standard mesh CTU Modern ML Platforms CTU: Custom fraud-specific; Modern: General-purpose MLOps PouchContainer containerd/cri-o Pouch: Alibaba-specific; containerd: CNCF standard 1. LDC Architecture vs Kubernetes Multi-Cluster Kiến Trúc So Sánh ┌─────────────────────────────────────────────────────────────────────────────┐ │ LDC (Alipay) vs Kubernetes Multi-Cluster │ ├─────────────────────────────────────────────────────────────────────────────┤ │ │ │ LDC Architecture (Business-Driven) │ │ ┌─────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ │ │ RZone 1 RZone 2 RZone N │ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ │ │Users │ │Users │ │Users │ │ │ │ │ │1-1M │ │1M-2M │ │N-M │ │ │ │ │ ├─────────┤ ├─────────┤ ├─────────┤ │ │ │ │ │Apps │ │Apps │ │Apps │ │ │ │ │ │DB │ │DB │ │DB │ │ │ │ │ │Cache │ │Cache │ │Cache │ │ │ │ │ └─────────┘ └─────────┘ └─────────┘ │ │ │ │ │ │ │ │ • Sharding: User ID-based │ │ │ │ • Self-contained units │ │ │ │ • Cross-unit = Distributed txn │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────┘ │ │ │ │ Kubernetes Multi-Cluster (Infrastructure-Driven) │ │ ┌─────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ │ │ Cluster 1 Cluster 2 Cluster N │ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ │ │Region: │ │Region: │ │Region: │ │ │ │ │ │us-west │ │eu-west │ │ap-south │ │ │ │ │ ├─────────┤ ├─────────┤ ├─────────┤ │ │ │ │ │K8s Pods │ │K8s Pods │ │K8s Pods │ │ │ │ │ │Services │ │Services │ │Services │ │ │ │ │ └─────────┘ └─────────┘ └─────────┘ │ │ │ │ │ │ │ │ • Sharding: Infrastructure/region-based │ │ │ │ • Shared global services │ │ │ │ • Cross-cluster = Service mesh │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ Detailed Comparison Aspect LDC (Alipay) K8s Multi-Cluster Recommendation Sharding Strategy User ID / Business key Node/Region labels LDC approach cho data-intensive apps Unit Boundary App + Data + Cache Pods + Services LDC: true isolation; K8s: shared storage Cross-Unit Traffic Explicit ( costly ) Transparent via mesh LDC: intentional design; K8s: hide complexity Failover Manual/Scripted (RZone switch) Automatic (health checks) K8s wins cho automation Scaling Add RZone (complex) Add nodes (simple) K8s wins cho ops simplicity Data Consistency Strong (Paxos in unit) Eventual (cross-cluster) LDC wins cho financial data Khi Nào Dùng Cái Nào? Use LDC-style khi: ...