# क्षमता, Upgrades और Managed Services — Apache Kafka: बुनियाद से Production तक Event Streaming

Source: https://www.geekswithgeeks.com/hi/kafka/ops-capacity-managed

> Storage और throughput की योजना बनाएँ, upgrades सुरक्षित रूप से लागू करें और self-managed व managed Kafka में चुनें।

## योजना बनाएँ, फिर गुंजाइश रखें

**Storage** (प्रतिदिन डेटा × retention × replication factor, साथ में लगभग 20-30% गुंजाइश), **network** (अंदर आते producers + replication + बाहर जाते consumers) और **प्रति broker partitions** का अनुमान लगाएँ। Upgrade **rolling restarts** से, एक बार में एक broker, release notes और upgrade क्रम का पालन करते हुए करें, और पहले staging में परखें। तय करें कि cluster कौन चलाएगा: **self-managed** (पूरा नियंत्रण, upgrades, सुरक्षा और on-call के लिए विशेषज्ञता चाहिए) या **managed service** (Confluent Cloud, Amazon MSK, Kafka के लिए Azure Event Hubs, Redpanda Cloud और अन्य) जो कुछ नियंत्रण और लागत के बदले कम संचालन-काम देती है। Brokers को availability zones में फैलाएँ और rack awareness चालू करें ताकि replicas अलग zones में रहें।

## क्षमता worksheet

अंक उदाहरण हैं। मुद्दा हार्डवेयर ख़रीदने या plan चुनने से पहले गणना करना है।

```text
Ingress                 20 MB/s average, 60 MB/s peak
Replication factor      3  -> inter-broker traffic ~ 2 x ingress
Consumers               3 groups -> egress ~ 3 x ingress
Retention               7 days -> 20 MB/s x 86,400 s x 7 x 3 replicas ~ 36 TB raw, +25% headroom
Brokers                 6 across 3 AZs (rack awareness on)
Partitions              ~1,000-2,000 per broker is a comfortable range for most clusters
```

**Quiz:** Brokers को एक बार में एक क्यों upgrade करें?

- [x] ताकि पर्याप्त in-sync replicas उपलब्ध रहें और writes चलते रहें
- [ ] Brokers एक साथ restart नहीं हो सकते
- [ ] इससे upgrades मुफ़्त हो जाते हैं
- [ ] सिर्फ़ managed services के लिए

*Answer:* ताकि पर्याप्त in-sync replicas उपलब्ध रहें और writes चलते रहें. सभी brokers एक साथ restart करने से min.insync.replicas से नीचे जाकर writes रुक जाते।