Design a Kafka topic schema for an e-commerce order processing system.

A common design is event topics named by domain, for example orders.order.created, orders.order.cancelled, payments.payment.completed, payments.payment.failed, inventory.reservation.confirmed. Key the order events by orderId: events with the same key are written to the same partition, and Kafka guarantees order only within a partition. That also means events in different topics have no ordering relative to each other, so if consumers need an order's whole lifecycle in sequence, a single orders topic keyed by orderId carrying an event type is an alternative. Serialize with a schema-based format such as Avro and a schema registry, with compatibility rules and a version field so events can evolve. For critical topics a replication factor of 3 is a common production setting (the broker default default.replication.factor is 1), usually combined with min.insync.replicas=2 and producers using acks=all. Retention is set per topic (retention.ms defaults to 7 days); a longer retention, or a separate topic, can serve audit needs. Give each service its own consumer group so that every service receives all events. Failed records can go to a dead-letter topic per consumer (Spring Kafka's default is <topic>-dlt). Choose the partition count from the parallelism and throughput you need.

Expected key concepts: orderId, Avro, schema registry, partition, min.insync.replicas, retention.ms, dead-letter topic