Topic 16.5
Designing a Payment Event Platform
In one line
Payment events (Created, Authorized, Captured, Failed, Refunded) demand strict per-payment ordering, no loss, no double effects, full auditability and long retention. Combine outbox publishing, RF 3 / acks=all / min.insync=2, idempotent consumers keyed on payment IDs, schemas with strict compatibility, DLTs with human review, and replayable history.
Think of it like this
A bank's clearing house. Every instruction is recorded in order, nothing is ever lost or processed twice, every step is auditable years later, and anything unusual goes to a human queue.
Key ideas
- 01
Topic
payments.eventskeyed by paymentId (per-payment order), RF 3, min.insync 2, unclean election off, retention long (months to years, tiered storage) or archived to immutable storage for audit. - 02
Producers: payment service via transactional outbox, so a payment state change and its event commit together.
- 03
Consumers: ledger (double-entry postings, idempotent by event ID), notifications, fraud, reconciliation, analytics. External calls (acquirers, banks) use idempotency keys.
- 04
Schemas: Avro/Protobuf, FULL_TRANSITIVE compatibility, amounts as integer minor units plus currency, no card data (tokens only).
- 05
DLT: payment events that can't be processed go to a DLT reviewed by operations with runbooks; never auto-drop.
- 06
Security and compliance: strict ACLs, encryption in transit and at rest, audit logs of access, data residency per region.
Code & diagrams
Interview problem
The problem
Design a payment event platform
Design Kafka for PaymentCreated, PaymentAuthorized, PaymentCaptured, PaymentFailed and Refunded events. Discuss ordering, idempotency, durability, schema, audit, replay and DLT, using the full reasoning chain.
You're given
- 20K payments/sec peak
- Zero loss of acknowledged events
- 7-year audit retention
- Multiple regions
Explain it without notes
What guarantees does Kafka provide for payments, and what must the application guarantee?
Practice
Write the configuration list (topic, producer, consumer) for the payment platform.
Trade-offs
- ↔
Maximum safety costs throughput headroom and operational care; for payments, that's the right trade.
Done when you can
I can design a payment event platform with the full reasoning chain and failure handling.