Chọn broker và vận hành production
Chọn theo semantics, failure model và operational burden của workload — không theo độ phổ biến, benchmark marketing hay mong muốn chuẩn hóa một công nghệ cho mọi flow.
1. RabbitMQ và Kafka thiên về gì?
| Nhu cầu | RabbitMQ thiên về | Kafka thiên về |
|---|---|---|
| Work queue / command dispatch | Queue ownership, ack, flexible routing | Có thể làm nhưng offset/log model khác |
| Per-message routing | Direct/topic/fanout/headers exchanges | Topic + partition key đơn giản hơn |
| Retention và replay | Không phải core consumption model | Core strength, offsets độc lập |
| Nhiều independent consumers | Bindings tạo queue copies | Nhiều groups đọc cùng log |
| Delay/TTL/DLX | Primitives tích hợp/policy | Retry topics/processors/scheduler |
| Stream processing | Application tự xây nhiều hơn | Log/partition/transaction ecosystem |
| Fine-grained queue priority | Có queue features phù hợp workload | Thường model bằng topics/consumers |
| Ordering | Ràng buộc queue/channel; cần kiểm tra concurrency và redelivery | Per partition, không phải toàn topic |
Đây là khuynh hướng, không phải “có/không” tuyệt đối. POC phải bao gồm failure, backpressure, security và recovery; happy-path throughput không đủ để quyết định.
Follow-up · Jobs, audit events và notifications
Choose RabbitMQ or Kafka for jobs, audit events and notifications.
Dùng cùng decision matrix cho cả ba workload. Với notifications, nêu rõ routing/fan-out, retention/replay, ordering và cách xử lý duplicate ở side effect. Ghi lại assumptions và lý do chọn broker, không chỉ nêu tên công nghệ.
Đây là follow-up của câu 23–24 trong bộ 30 câu hỏi, không phải câu hỏi hay lab mới.
2. Requirement và semantics checklist
- Ai sở hữu backlog, và khi consumer đọc thì data có cần giữ cho consumer khác/replay không?
- Ordering cần global, per aggregate hay không cần? Key/routing nào tạo scope đó?
- Maximum tolerable loss, duplicate và processing delay là bao nhiêu?
- Poison message, retry delay, unknown outcome và idempotency được xử lý ở đâu?
- Retention, deletion, PII và legal hold có yêu cầu gì?
- Cross-region RPO/RTO, failover/failback và replay rate là bao nhiêu?
3. Capacity model và SLO
Ước lượng steady/burst message rate, payload distribution, routing fan-out, compression, retention/backlog, replication, producer confirms/acks, consumer service time và recovery catch-up. Capacity phải còn headroom khi một node/AZ mất hoặc khi reassign/compact/replay.
SLO nên gồm publish availability/latency, end-to-end processing age, loss/duplicate tolerance, retry/DLQ age, replay throughput và recovery RTO. Benchmark cùng TLS, auth, durability, schema, client batching và payload thật.
4. Security, governance và data lifecycle
Dùng TLS, authentication, least privilege theo vhost/exchange/queue hoặc topic/group/transactional ID, credential rotation, quotas và audit. Hạn chế management/admin APIs và không cho ứng dụng tùy ý tạo topology/topic production.
Message chứa PII/secret cần minimization, encryption-at-rest/in-transit theo threat model, retention/deletion và access audit. Encryption không thay authorization; schema registry, connectors và monitoring endpoints cũng thuộc attack surface.
- Ownership catalog cho topic/queue, schema, producer và consumer.
- Quota ngăn một tenant/client làm cạn storage/network.
- Change review cho retention, partition count, DLX và ACL.
- Credential/CA rotation được test mà không reconnect storm.
5. Incident diagnosis patterns
| Triệu chứng | Phân biệt | Action đầu tiên |
|---|---|---|
| Backlog/lag tăng | Ingress spike, slow consumer/downstream, skew, broker saturation | Stop amplification, đo per queue/partition age/rate |
| Rebalance storm | Poll timeout, GC, network, deploy churn | Stabilize membership và bounded processing |
| DLQ spike | Schema/permanent/transient/permission | Dừng replay, classify sample, bảo vệ downstream |
| Publish latency | Broker alarm, ISR/quorum, disk/network, client buffer | Giảm ingress và bảo vệ durability |
| Hot partition/leader | Key skew, placement, single queue workload | Confirm distribution trước khi rebalance |
6. Migration và coexistence
Dual publish trực tiếp từ business transaction dễ diverge khi một broker thành công và broker kia fail. Dùng outbox/relay, stable event ID và reconciliation ledger. Backfill/replay phải giữ key/order, schema version, rate limit và downstream idempotency.
Thiết kế shadow consumer để so count/content/order trước cutover; canary producer/consumer; define source of truth trong từng phase; giữ rollback không tạo double processing. Không đổi broker nếu chưa lượng hóa requirement hiện tại không đáp ứng hoặc operational cost cải thiện.