Card purchase

Synchronous authorization, and a single event consumed independently by antifraud, notifications, cashback, and analytics.

This case study shows the most common event-driven architecture pattern in payment systems: a synchronous, critical decision (whether to authorize the purchase) followed by a single event that multiple systems consume completely independently, each concerned with a different responsibility.

The domain event

The authorization itself — approving or denying the purchase at the moment the card is charged — is not done via Kafka. It's a synchronous call, with a millisecond response, between the payment terminal (or payment gateway) and the autorizacao-service, which decides based on available balance/limit. This is intentional: Chapter 1 already explained that request/response communication needing an immediate answer isn't Kafka's use case.

What happens after the synchronous decision is where Kafka comes in: as soon as the purchase is approved, the autorizacao-service publishes a CompraAutorizada event — a fact that already happened — and moves on, without knowing (or needing to know) who will react to it.

{
  "eventId": "3a91f7c2-...",
  "cartaoId": "card_88213",
  "clienteId": "cli_50213",
  "valor": 15990,
  "estabelecimento": "Loja XYZ",
  "categoria": "varejo",
  "autorizadoEm": "2026-07-31T18:44:02Z"
}

Topic topology

Topic and configuration

Item	Decision
Topic	`compras.autorizadas`
Key	`cartaoId`
Partitions	18
Replication factor	3
Retention	15 days

Why the key is `cartaoId`, not `clienteId`

Dica de entrevista

The choice between cartaoId and clienteId as the key is a great test of ordering understanding (Chapter 4). If a customer has multiple cards and the requirement is only "process purchases on the same card in order" (e.g., to detect a suspicious sequence of purchases on the same card in a short window), the correct key is cartaoId. If the requirement were to consolidate the customer's behavior as a whole, regardless of which card was used, clienteId would be the choice — trading per-card ordering for per-customer ordering. There's no universally correct answer; it depends on which ordering relationship the domain actually needs.

Independent consumers

Multiple Consumer Groups read the same compras.autorizadas topic independently.

antifraude-service: assesses the purchase against risk rules (spending pattern, geolocation, velocity between transactions). In suspicious cases, it may publish a separate CompraSuspeita event to trigger a preventive card block.
notificacao-service: sends a push notification, "Purchase of R$ 159.90 approved at Loja XYZ."
cashback-service: calculates and credits applicable cashback, based on the merchant's category.
analytics-service: feeds a data warehouse for spending dashboards and recommendation models.

None of these four consumers know the other three exist. A slowdown in analytics-service (for example, during a heavy report-reprocessing load) doesn't delay the push notification, which needs to be nearly instant for a good customer experience.

Idempotency: not every consumer needs the same rigor

The level of duplication protection varies by consumer

The four consumers of this event have very different idempotency requirements — a common mistake is applying the same protection pattern (a processed-events table) to all of them, when some are already naturally tolerant of duplication.

Idempotency requirement per consumer

Consumer	Effect of duplication	Required protection
`cashback-service`	Cashback credited twice — direct financial loss	`eventId` + uniqueness constraint, mandatory
`notificacao-service`	Customer gets two notifications — annoying, not critical	No special protection needed
`antifraude-service`	Re-evaluates the same purchase twice — redundant work, not incorrect	Optional, for efficiency, not correctness
`analytics-service`	Purchase counted twice in the aggregation — inflated metrics	Depends on the query: `eventId`-based upsert aggregations solve this naturally

Retry and DLQ

The cashback-service, since it handles direct financial value, uses retry with backoff and a DLQ (Chapter 9): if the cashback calculation rule fails (e.g., the category table is unavailable), the message is reprocessed up to 3 times before going to compras.autorizadas.cashback.dlq, without blocking cashback credit for the following purchases.

Replay

If the cashback category table is retroactively corrected (a category that should give 2% was configured with 1%), the cashback-service can replay the last 15 days (within retention) to recalculate and credit the difference — as long as the credit logic is an upsert by eventId, avoiding duplicating cashback already correctly credited.

Observability

What each team monitors

Team	Priority metric
Cashback	Consumer lag and error rate — a delay here turns into a customer complaint about missing cashback
Notifications	Producer → consumer latency — the push needs to arrive within seconds to have value
Antifraud	DLQ message rate — risk-assessment failures can't go unnoticed
Analytics	Consumer lag aggregated over the day — a delay here is tolerable in minutes, not seconds

Resumo

This case illustrates the difference between synchronous communication (the authorization itself, outside Kafka) and asynchronous (everything reacting to the already-approved purchase). A single event, CompraAutorizada, is consumed by four systems with completely different latency, idempotency, and failure-tolerance needs — each configured according to its own criticality, not a single pattern applied indiscriminately to all of them.

Related chapters