Accelerating real-time alerts with Redpanda: a successful migration story

Redpanda · 2023 · 2. Tăng trưởng · Độ khó: Dễ — bài gốc

Bài khách (Eric Laguer, Equal Experts, một công ty dịch vụ IT) đăng trên blog của nhà cung cấp, kể dự án cho một khách FinTech không nêu tên. Ít số liệu (không có con số latency trước/sau); mọi nhận định ghi "theo Equal Experts".

Bối cảnh

• Khách FinTech cần hệ cảnh báo dữ liệu thị trường độ trễ thấp: trung bình đầu-cuối vài chục ms.
• Stack đề xuất ban đầu: Kafka, Kafka Connect, Flink, ksqlDB, Vert.x. Khó cân số partition: ít quá thì Flink không tận dụng được chia dữ liệu, nhiều quá thì metadata của Kafka trong ZooKeeper thành gánh nặng.

Thay đổi chính

• Thử Kafka managed trước: không đạt mục tiêu latency, lại gặp giới hạn chi phí do bị throttle vì transaction của ksqlDB.
• Chuyển sang Redpanda (tương thích Kafka API, một binary C++ gồm broker, HTTP proxy, schema registry, Raft). Theo Equal Experts, benchmark cho latency thấp ngang Kafka chạy không replication (lựa chọn rủi ro cho production).
• Chọn tự host thay vì Redpanda Cloud để kiểm soát loại máy: chạy trên EC2 Graviton (ARM) thay vì Kubernetes, theo họ nhanh hơn khoảng 20% và rẻ hơn.
• Migration đơn giản vì giữ nguyên client Java của Kafka. Hệ được thiết kế bằng microservice lỏng, nên thay nền streaming chỉ ảnh hưởng một thành phần. Phần mất công: SASL, script Terraform/Ansible, metric Prometheus, cấu hình schema registry cho DR.

Vì sao

• Theo Equal Experts: đạt p99 latency mỗi hop topic mà khách cần, ít thành phần vận hành hơn.

Bài học cho SWE

• Trước khi đổi nền message, đo baseline latency/throughput của hệ cũ; load test hệ mới trên nhiều loại máy; chỉnh config client theo mục tiêu latency (Event-driven, message queue và Kafka).
• Giao thức tương thích (Kafka API) làm đổi nền gần như chỉ là đổi địa chỉ; coupling lỏng giữa service giới hạn vùng ảnh hưởng.
• Managed service tiện nhưng có thể chặn đúng thứ mình cần (latency, loại máy, giới hạn throttle).

Liên quan

• Redpanda 2026 · Redpanda 2026 · WarpStream 2025 (đổi Kafka vì lý do ngược lại: chi phí, không phải latency)
• Event-driven, message queue và Kafka · Chọn database theo workload