Event-driven order processing

In practice you build effectively-once: the broker delivers at least once, and consumers are idempotent. Store processed message IDs (or use a natural idempotency key) and skip duplicates, ideally in the same transaction as the side effect. Kafka's transactions give exactly-once within Kafka, but external side effects still need idempotency.

Writing to the database and publishing to a broker are two systems, so one can succeed while the other fails. The outbox writes the event into a table in the same transaction as the business change; a relay (polling or CDC) then publishes it. Events are never lost and never sent for a change that did not commit.

Benefits: services are loosely coupled, can scale and fail independently, new consumers can be added without changing producers, and work is absorbed by queues during spikes. Costs: eventual consistency, harder debugging across services, duplicate and out-of-order messages, and the need for good observability and schema management.

A command asks a specific service to do something (ChargePayment) and expects it to be handled once. An event announces something that already happened (OrderPlaced) and any number of consumers may react. Naming and ownership follow from that: commands go to one owner, events are broadcast.

Give every event a unique ID, record processed IDs (in the same transaction as the side effect when possible), and skip duplicates. Design updates to be naturally idempotent (set status to PAID rather than add amount) and use idempotency keys for external calls.

In choreography, each service listens for events and emits the next one; there is no central controller, which is decoupled but hard to follow. In orchestration, a coordinator (like a workflow engine) tells each service what to do and handles compensation, which is easier to reason about and monitor.

Use a saga: each step is a local transaction that emits an event, and each has a compensating action (refund the payment, release the stock) if a later step fails. Choreography lets services react to each other's events; orchestration uses one coordinator that tracks the steps.

Use a schema registry with Avro, Protobuf or JSON Schema, make backward-compatible changes (add optional fields, never rename or change types), version event types for breaking changes, and let consumers ignore unknown fields.

Partition by entity so one entity's events stay ordered, include a sequence number or version in events, and have consumers ignore events older than the state they already applied, or buffer briefly to reorder.

Storing the sequence of events as the source of truth instead of current state. State is rebuilt by replaying events, giving a complete audit history and time travel, at the cost of complexity, snapshotting for performance and careful schema evolution.

Command Query Responsibility Segregation separates the write model from read models. Events from the write side update one or more read models (projections) optimised for queries, which are eventually consistent.

Propagate a correlation or trace ID in every event's headers, use distributed tracing (OpenTelemetry), log structured events with IDs, and build a timeline view per order from the event log.

Kafka is a durable, partitioned log with replay and high throughput, suited to event streaming and many consumer groups. RabbitMQ is a flexible message broker with routing and per-message acknowledgements. SQS is a fully managed queue with minimal operations. Choose by replay needs, ordering, throughput and operational capacity.

After a limited number of retries with backoff, move it to a dead-letter queue with the error details, alert, and let the consumer continue. Fix the bug or data, then replay the DLQ messages.

Either make events carry enough state (event-carried state transfer) so consumers do not need to call back, or let the consumer query the owning service's API on demand. For new consumers, backfill by replaying the log or loading a snapshot before consuming live events.

Publish schemas in a registry with owners, versions and examples, use a consistent envelope (event ID, type, source, time, correlation ID), document guarantees such as ordering keys and retention, and treat event contracts like public APIs with deprecation periods.

Each partition is consumed by one member of a group, so adding consumers up to the number of partitions increases parallelism. More partitions allow more parallelism but add overhead, and ordering holds only within a partition.

At-least-once acknowledges after processing, so crashes cause redelivery and duplicates. At-most-once acknowledges before processing, so crashes lose messages. Most systems choose at-least-once with idempotent consumers.

Reset the consumer group's offset (or create a new group) and reprocess from the beginning of the retained log into a fresh store, then switch reads to it. This requires long enough retention or a compacted topic.

A Kafka topic that keeps at least the latest value for each key, removing older values over time. It works like a changelog table, useful for state that consumers need in full, such as current prices.

Give each consumer its own queue or consumer group, size it independently, and monitor lag per consumer. A slow consumer only builds up its own backlog.

Make the shipping service react to a PaymentCaptured event rather than OrderPlaced, or have an orchestrator call shipping only after the payment step succeeds; enforce state transitions in the order service.

Consumers store incoming message IDs in an inbox table in the same transaction as their state changes, so redelivered messages are detected and skipped, complementing the outbox pattern on the producer side.

A domain event records something meaningful inside one service's model and may carry internal detail. An integration event is the stable, public version published for other services, with only the fields they need, so internal refactors do not break consumers.

Messages wait in the broker, so the consumer catches up when it returns. Size retention to cover the outage, make catch-up idempotent, watch lag, and consider extra consumers to drain the backlog faster once it recovers.

Never react to your own published events, mark events with their source and a hop count or correlation ID, make handlers idempotent, and design flows as a directed graph so an update in service A does not trigger an update back in A through B.

When you need stateful work over events, such as joins, windows, aggregates or deduplication, with exactly-once state updates and fault-tolerant checkpoints, rather than handling each message independently in a simple consumer.

Track consumer lag, processing latency, error and retry rates, DLQ size, throughput per topic, and end-to-end time from event to effect for key flows, with alerts on growing lag.

For simple CRUD apps with one team, low scale and strong consistency needs. A modular monolith with a database transaction is simpler until there is a real need to decouple.

Unit-test handlers with sample events, use contract tests for event schemas between producers and consumers, run integration tests with a real broker in containers, and test duplicate and out-of-order delivery explicitly.

The event type, a unique ID, the entity ID, a timestamp, a version, and the data consumers need (or a reference to fetch it). Avoid huge payloads and sensitive data that consumers do not need.

Publish references instead of personal fields, encrypt sensitive fields with per-user keys so deleting the key erases them (crypto-shredding), and set retention or compaction so data does not live longer than policy allows.

1. AExactly-once end to end
2. BNo guarantee
3. CAt-most-once
4. DAt-least-onceCorrect answer

Why: Messages are redelivered until acknowledged, so duplicates are possible and consumers must be idempotent.

1. AA database query
2. BA UI action only
3. CSomething that already happenedCorrect answer
4. DAn order to do something

Why: Commands ask; events announce.

1. ADelete the topic
2. BRestart the broker
3. CIdempotent consumers keyed by event IDCorrect answer
4. DHope they never happen

Why: At-least-once delivery creates duplicates.

1. AEvent sourcing
2. BCQRS
3. COrchestrationCorrect answer
4. DChoreography

Why: The coordinator handles compensation.

1. ASetting a higher replication factor
2. BUsing consumer groups
3. CUsing many topics
4. DSending them with the same partition keyCorrect answer

Why: Ordering is guaranteed only within a partition, and the key decides the partition.

1. AIt is deleted silently
2. BTo a dead-letter queueCorrect answer
3. CBack to the producer
4. DTo the primary database

Why: A dead-letter queue parks poison messages so the rest of the stream keeps flowing and someone can inspect them.

1. ARemoving a required field
2. BAdding an optional fieldCorrect answer
3. CRenaming a field
4. DChanging a field's type

Why: Old consumers ignore new optional fields.

1. AOnly logs
2. BThe sequence of events as the source of truthCorrect answer
3. COnly current state
4. DOnly snapshots

Why: State is rebuilt by replay.

1. AFrontend from backend
2. BTests from code
3. CQueues from topics
4. DThe write model from read modelsCorrect answer

Why: Reads use projections.

1. AA correlation or trace IDCorrect answer
2. BThe server name
3. CThe queue name
4. DThe timestamp only

Why: Enables distributed tracing.

1. AKafkaCorrect answer
2. BSMTP
3. CMemcached
4. DFTP

Why: Retention allows replay.

1. ABroker version
2. BThe number of partitionsCorrect answer
3. CThe number of topics
4. DMessage size

Why: One consumer per partition per group.

1. AEvents include the data consumers needCorrect answer
2. BConsumers always call back for data
3. CEvents carry only an ID
4. DState is stored in the broker config

Why: Consumers can act without a synchronous call to the owner.

1. AAlways larger
2. BA stable public contract for other servicesCorrect answer
3. CNever persisted
4. DOnly used in tests

Why: Public events shield consumers from internal model changes.

1. ALosing messagesCorrect answer
2. BDuplicate messages
3. COut-of-order only
4. DNothing

Why: Acknowledged before processing.

1. AEvery message forever
2. BOnly the first message
3. CNothing after a day
4. DThe latest value per keyCorrect answer

Why: Works like a changelog table.

1. ASidecar
2. BInboxCorrect answer
3. COutbox
4. DStrangler

Why: Stores processed IDs.

1. ADelete the topic
2. BReplay events into a fresh storeCorrect answer
3. CEdit rows manually
4. DRestart consumers

Why: Needs enough retention.

1. AOn OrderPlaced
2. BBefore payment
3. CAt random
4. DAfter a PaymentCaptured eventCorrect answer

Why: React to the right event.

1. AThe client
2. BA dead-letter queueCorrect answer
3. CThe main queue again forever
4. DThe database

Why: So other messages keep flowing.

1. AAcross partitions
2. BNever
3. CWithin a partitionCorrect answer
4. DAcross all topics

Why: Partition by entity key.

1. ADNS latency
2. BConsumer lagCorrect answer
3. CCPU idle
4. DDisk free

Why: Alert when lag keeps growing.

1. ANowhere
2. BA schema registry with owners and versionsCorrect answer
3. CPrivate chat messages
4. DOnly in producer code

Why: Shared schemas let teams discover and validate events.

1. AThey wait in the broker for catch-upCorrect answer
2. BThey are lost immediately
3. CThey go to the producer
4. DThey are converted to emails

Why: Durable brokers decouple producer and consumer uptime.

1. AA cron job
2. BA CDN
3. CA load balancer
4. DA stream processor like FlinkCorrect answer

Why: Stream processors manage state and checkpoints for you.

1. ARestarting brokers
2. BDeleting the per-user encryption keyCorrect answer
3. CRewriting every log segment
4. DRenaming the topic

Why: Encrypted fields become unreadable once the key is gone.

1. AHigh-volume streams
2. BMany independent consumers
3. CSimple CRUD apps with one teamCorrect answer
4. DLarge multi-team platforms

Why: A transaction is simpler.

1. AVisual tests
2. BLoad tests
3. CContract testsCorrect answer
4. DSnapshot tests

Why: Catch breaking changes early.

1. ASQSCorrect answer
2. BKafka on EC2
3. CRabbitMQ on VMs
4. DRedis on EC2

Why: Fully managed by AWS.

1. AAdapter
2. BFacade
3. COutboxCorrect answer
4. DInbox

Why: Events are stored with the change.

1. AThe entity ID
2. BSensitive data consumers do not needCorrect answer
3. CAn event ID
4. DA timestamp

Why: Share only what is needed.

1. ABigger partitions
2. BShorter retention
3. CMore consumers
4. DIgnoring your own events and tracking the sourceCorrect answer

Why: Knowing an event's origin stops it bouncing back.