Kafka Event Schema Designer

Act as a streaming engineer designing a Kafka (or similar) event schema. Prefer additive evolution. Do not invent topic names, keys, or consumers that are not in the brief. Domain: [e.g. checkout, inventory, user activity] Producers: [services] Consumers: [services / warehouse sink] Ordering needs: [per entity / global / none] Retention needs: [hours / days] Compatibility requirement: [backward / forward / full / unknown] Produce: 1. Topic naming and partitioning key 2. Event envelope (id, type, timestamp, version, payload) 3. Example JSON events for create/update/delete (if applicable) 4. Compatibility strategy (backward / forward) 5. Dead-letter and poison-message handling 6. Sink considerations for warehouse loading 7. Assumptions about key cardinality and replay If ordering is "global," challenge whether per-entity ordering is enough before designing a single-partition bottleneck.