# केस स्टडी: E-commerce Platform के लिए Order Events — Apache Kafka: बुनियाद से Production तक Event Streaming

Source: https://www.geekswithgeeks.com/hi/kafka/wrap-orders-case

> Billing, fulfilment और analytics द्वारा उपभोग किए जाने वाले order events के लिए Kafka setup डिज़ाइन करें।

## डिज़ाइन

Topic `sales.order.placed.v1`: **key = `order_id`** (किसी order के सभी events क्रम में रहते हैं), **12 partitions** (throughput गणना से, गुंजाइश के साथ), **replication factor 3**, `min.insync.replicas=2`, retention 7 दिन। Registry के साथ Avro में schema और **backward compatibility**। Order service `acks=all`, idempotence चालू, `linger.ms=10`, `lz4` के साथ produce करती है। तीन consumer groups स्वतंत्र रूप से पढ़ते हैं: **billing** (idempotent database write के बाद manual commit, ख़राब records के लिए DLT), **fulfilment** (cooperative-sticky assignor), **analytics** (lake में sink connector)। Monitoring प्रति group lag, under-replicated partitions और DLT आकार ढकती है। Access प्रति service ACL से, हर जगह TLS, और topic बदलाव code review से गुज़रते हैं।

## भरोसेमंद order-events pipeline

Key का चुनाव, टिकाऊ settings, idempotent consumers, monitoring और सुरक्षा मिलकर भरोसेमंद डिज़ाइन बनाते हैं।

![चार हिस्से: topic, producer, consumers, संचालन।](assets/figures/kafka/section-8-map.svg) — चित्र 8.1 — Topic, producer, consumers और संचालन।

## एक पन्ने पर डिज़ाइन

हर पंक्ति इस कोर्स के एक खंड से जुड़ती है।

```text
Topic        key=order_id, 12 partitions, rf=3, retention 7d     (Sec 1, 4)
Durability   min.insync.replicas=2, acks=all, idempotence, no unclean  (Sec 2, 5)
Schema       Avro + registry, backward-compatible                  (Sec 2)
Consumers    billing (manual commit + DLT), fulfilment, analytics   (Sec 3, 6)
Ops          lag/URP/DLT alerts, TLS + SASL + ACLs, rolling upgrades (Sec 7)
```

## Launch से पहले load-test करें

Staging cluster में यथार्थपूर्ण मात्रा replay करें, test के दौरान एक broker और एक consumer मारें, और पुष्टि करें कि lag सुधरता है और कोई record खोता या दोहरा लागू नहीं होता।

**Quiz:** केस स्टडी में `order_id` अच्छी key क्यों है?

- [ ] यह compression बंद करती है
- [ ] यह हर record को topics में अनोखा बनाती है
- [x] एक order के सभी events एक partition में जाते और क्रम में रहते हैं
- [ ] Kafka इसे ज़रूरी करता है

*Answer:* एक order के सभी events एक partition में जाते और क्रम में रहते हैं. प्रति-इकाई क्रम के लिए इकाई की ID को key बनाना होता है।