केस स्टडी: E-commerce Platform के लिए Order Events

डिज़ाइन

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        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 खोता या दोहरा लागू नहीं होता।

त्वरित जाँच: केस स्टडी में `order_id` अच्छी key क्यों है?

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