Twilio Segment ने microservices से monolithic architecture की ओर वापसी क्यों की

 (twilio.com)
5 पॉइंट द्वारा GN⁺ 2025-12-14 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • Twilio Segment ने सैकड़ों microservices वाले स्ट्रक्चर को चलाने के बाद, बढ़ती जटिलता और maintenance burden के कारण single service (monolithic) में बदलाव किया
  • शुरुआत में हर destination API को अलग करके failure isolation और scalability हासिल की गई, लेकिन services की संख्या 140 से अधिक होते ही operational overhead तेज़ी से बढ़ गया
  • कई repositories और shared libraries को manage करना मुश्किल हो गया, और testing तथा deployment के दौरान पूरे service set पर असर पड़ने लगा
  • इसे हल करने के लिए Centrifuge system और monorepo structure अपनाया गया, और test automation के लिए Traffic Recorder बनाया गया
  • नतीजतन development speed और stability में बड़ा सुधार हुआ, और Twilio Segment अब productivity और operational efficiency के लिए monolithic structure बनाए हुए है

microservices अपनाने और उनकी सीमाएँ

  • Twilio Segment ने customer data infrastructure के लिए microservices architecture अपनाया, जिसमें हर उद्देश्य-आधारित service को events को स्वतंत्र रूप से process करने के लिए design किया गया
    • यह सैकड़ों server-side destinations (जैसे Google Analytics, Optimizely आदि) तक data पहुंचाता था
    • शुरुआत में एक single queue का इस्तेमाल किया गया, लेकिन किसी खास destination में failure होने पर पूरे सिस्टम में delay पैदा करने वाली head-of-line blocking समस्या सामने आई
  • इसे हल करने के लिए हर destination के लिए अलग service और queue बनाई गई, जिससे failure isolation और independent scaling संभव हुआ
  • लेकिन services की संख्या बढ़ने के साथ operational complexity और maintenance cost तेज़ी से बढ़ी, जिसका असर development speed में गिरावट और defect rate में बढ़ोतरी के रूप में दिखा

अलग repositories और shared libraries की समस्या

  • हर destination अलग API format का इस्तेमाल करता था, इसलिए custom transformation code की जरूरत पड़ती थी
    • शुरुआत में इन्हें एक single repo में manage किया गया, लेकिन test failures का असर पूरे सिस्टम पर पड़ता था, इसलिए repo separation किया गया
  • बाद में 50 से अधिक नए destinations जुड़ने से 50 से अधिक repositories बन गईं
    • common functionality के लिए shared libraries लाई गईं, लेकिन version mismatch और deployment burden बढ़ गया
  • हर service के load patterns अलग थे, इसलिए autoscaling settings को configure करना मुश्किल था, और कई बार operators को manually adjustment करना पड़ता था

monolithic migration और Centrifuge का अपनाना

  • 140 से अधिक services को एक single service में consolidate करने का फैसला लिया गया
    • अलग-अलग queues की जगह Centrifuge system विकसित किया गया, जो सभी events को single service तक पहुंचाता था
    • बाद में Centrifuge, Twilio Segment के Connections backend infrastructure में विकसित हुआ
  • single service structure में बदलाव के साथ operational burden में कमी और incident response की सरलता हासिल हुई

monorepo और test automation

  • सभी destination code को एक repository में merge किया गया, और 120 से अधिक dependencies को एक single version पर standardize किया गया
    • इससे version management आसान हुआ और maintenance efficiency बेहतर हुई
  • test automation के लिए Traffic Recorder अपनाया गया
    • यह real HTTP request/response को record करके replay करता था, जिससे external network dependency हट गई
    • test speed कई मिनटों से घटकर milliseconds स्तर तक आ गई, और stability में बड़ा सुधार हुआ
  • test failure rate कम हुई और developer productivity में बड़ा सुधार आया

monolithic structure के प्रभाव और trade-offs

  • single service में consolidation के बाद deployment speed और development efficiency में बड़ा सुधार हुआ
    • 1 साल में shared libraries improvement की संख्या 32 से बढ़कर 46 हो गई
    • एक single engineer कुछ ही मिनटों में deployment कर सकता था
  • operational efficiency भी बेहतर हुई, और load spike के समय बड़े worker pool के जरिए ट्रैफिक absorb किया जा सका
  • हालांकि defect isolation में कठिनाई, cache efficiency में कमी, और dependency update risk जैसी कमियाँ भी रहीं
    • इनका कुछ हिस्सा operational simplicity और productivity gains से offset हो गया

निष्कर्ष

  • microservices ने शुरुआती performance समस्याएँ हल कीं, लेकिन large-scale expansion और batch updates के लिए वे उपयुक्त नहीं रहीं
  • monolithic migration ने operational stability और development speed दोनों में सुधार किया
  • सफल migration के लिए मजबूत testing framework और trade-offs को स्वीकार करने की तैयारी जरूरी है
  • Twilio Segment कुछ infrastructure में अब भी microservices रखता है, लेकिन server-side destinations के लिए monolithic model को अधिक उपयुक्त माना गया है

संबंधित पढ़ाई

2 टिप्पणियां

 
yangeok 2025-12-16

मुझे लगता है कि हर चीज़ को पूरी तरह तोड़कर normalize करना जोखिम भरा हो सकता है।
 
GN⁺ 2025-12-14
Hacker News की राय

  • अगर सभी destinations का कोड एक ही repo में इकट्ठा किया जाए, तो उन्हें एक single service में merge किया जा सकता था
    नतीजतन development productivity काफ़ी बढ़ गई। अब एक shared library बदलने पर 140 से ज़्यादा services deploy करने की ज़रूरत नहीं रही
    अब एक engineer कुछ ही मिनटों में deploy कर सकता था
    अगर library change की वजह से सभी services को फिर से deploy करना पड़े, तो वह असली service नहीं बल्कि distributed monolith architecture है
    shared library को पूरे service set में ज़बरदस्ती sync करना, service architecture की philosophy से मेल नहीं खाता

    • तुम्हारी बात में दम है, लेकिन असल में मामला कहीं ज़्यादा complex है
      यह “हर library update पर full redeploy” से ज़्यादा Amazon-style shared build·deploy system के क़रीब है
      libraries एक centrally managed single source से लाई जाती हैं, और version अलग होने पर compatibility issues की वजह से सबको migrate करना पड़ता है
      जब किसी security vulnerability के कारण किसी specific version को हटाना हो, तब full redeploy ज़रूरी होता है, लेकिन centralized management के फ़ायदे उससे कहीं बड़े हैं
      ऐसी systems को अब भी microservices कहा जाता है, लेकिन cost और operational efficiency के लिहाज़ से ये shared environment की तरह काम करती हैं
      इसे distributed monolith कहना कुछ ज़्यादा ही interpretation है
    • कहना आसान है, लेकिन असल में services के बीच सूक्ष्म bugs या incompatibility पैदा होना बहुत आसान है
      microservices pattern अपनाने पर deployment risk बढ़ता है, बस शुरुआत में वह साफ़ दिखाई नहीं देता
      उदाहरण के लिए, अगर money-related library में bug fix किया है, तो व्यवहारिक रूप से सोचना पड़ता है कि क्या सभी services को फिर से deploy करना चाहिए
    • सिर्फ़ इसलिए कि library को system-wide upgrade करना पड़े, यह ज़रूरी नहीं कि वह गलत coupling हो
      security vulnerability वाली library को system design से अलग, हर हाल में पूरी तरह replace करना ही पड़ता है
      ऐसे मामलों में monolithic architecture को संभालना उल्टा ज़्यादा आसान होता है
    • shared library की अवधारणा ही सभी services को strongly coupled बना देती है
      असली microservices में messages का आदान-प्रदान होना चाहिए, और JSON का इस्तेमाल होना चाहिए
      code नहीं, सिर्फ़ API जानना काफ़ी होना चाहिए। तभी हर service को independently deploy और scale किया जा सकता है
    • तो क्या इसका मतलब है कि 140 services में से हर एक में logging code फिर से लिखना होगा?
      shared module का इस्तेमाल करना ज़्यादा तर्कसंगत नहीं है?

  • पिछली कंपनी में सब कुछ microservices पर चलता था, और उससे पहले वाली कंपनी AWS serverless थी
    दोनों ही मामलों में services के बीच communication सबसे बड़ी समस्या थी। contracts को sync करना मुश्किल था, और deployment भी complex था
    शुरुआत में काम तेज़ी से हुआ, लेकिन समय के साथ complexity फट पड़ी। fear-based development होने लगा और meetings बहुत ज़्यादा हो गईं
    मौजूदा कंपनी monolithic architecture पर है, और उसे संभालना कहीं आसान है। types साफ़ हैं, और refactoring सरल है
    अपने platform पर बने AI agents को codebase के अंदर खुद को सुधारते देखना दिलचस्प है
    कमी बस इतनी है कि build time लंबा है, लेकिन toolchain में सुधार के साथ 2026 तक 10x faster deployment की उम्मीद है
    मेरा निष्कर्ष यह है कि monolithic architecture की वजह से हम कहीं तेज़ी से grow और scale कर पाए

    • मेरा अनुभव बिल्कुल उल्टा है। SendGrid में 10 साल काम करते हुए हमने 12 लोगों से 500 लोगों तक scale किया, और यह service architecture की वजह से संभव हुआ
      monolithic architecture में हमेशा separation of concerns टूट जाता था, और teams के बीच coupling बहुत बढ़ जाती थी
      असली speed और scale तभी संभव हुआ जब teams अलग-अलग थीं
      ORM से DTO में switch करने के लिए 2 साल, 50 teams और 150 से ज़्यादा लोगों की ज़रूरत पड़ी
      इतना complex काम microservices के बिना संभव नहीं था

  • इस लेख को देखकर लगता है कि असली समस्या microservices vs monolith का technical choice नहीं, बल्कि
    engineering organization की quality और structure है
    code repository और test structure संगठन के स्तर को वैसे का वैसा दिखाते हैं

    • कई teams में technical discipline की कमी होती है
      अगर “यह मत करो” कहने वाला कोई न हो, तो complexity फट पड़ती है
      authority वाला leader होना चाहिए, ताकि team रुककर सोच सके
    • मैंने Twilio project पर साथ काम किया था, और वह सच में बुरी तरह अव्यवस्थित था
      API issue होने पर root cause analysis नहीं किया जाता था, बस data fix करके ticket बंद कर दिया जाता था
      वही समस्या बार-बार आती रही, लेकिन मूल कारण कभी हल नहीं किया गया
    • Conway’s Law एक बार फिर सही साबित हुआ
      सिर्फ़ interview करके भी किसी कंपनी के codebase structure का कुछ हद तक अंदाज़ा लगाया जा सकता है

  • यह सच में monolith migration से ज़्यादा अब भी SOA structure ही है
    बस service का scope बड़ा हो गया है
    अगर 140 services को एक ही team manage कर रही है, तो SOA team scaling के लिए है, service scaling के लिए नहीं
    अगर एक team सभी shared libraries manage करे, तो version mismatch और API confusion पैदा होता है
    आख़िरकार organizational structure ही architecture तय करता है। एक team ने complexity कम करने के लिए integration किया
    यह “monolith” नहीं, बल्कि team unit के हिसाब से ठीक तरह scoped service level है
    मुझे लगता है कि यही सबसे आदर्श structure है। team बड़ी हो जाए तो फिर दोबारा अलग करना चाहिए

  • मैं microservices supporter नहीं हूँ, लेकिन “monorepo vs microservices” वाली fake dichotomy साफ़ दिखती है
    बहुत सारे tools यह मानकर चलते हैं कि service और repo का रिश्ता 1:1 है
    लेकिन सब कुछ एक repo में रखकर भी independently deploy किया जा सकता है
    अच्छा होता अगर GitHub जैसी जगहों पर folder unit के हिसाब से उन्हें independent services की तरह treat किया जा सकता

    • मैंने पिछली कंपनी में इसे खुद implement किया था
      Bazel से dependency tree manage किया, और bazel query से affected targets खोजकर tests अपने आप चलाए
      GitHub Actions के साथ जोड़कर PR block करने वाला workflow बनाया
      यह अच्छी तरह चला, लेकिन इसे बनाने में कई महीने लगे
    • “microservices से monolith में बदला और problems गायब हो गईं” वाली बात खटकती है
      असली समस्या operations और tooling की कमी थी — CI, autoscaling, on-call system, सब कुछ कमज़ोर था

  • दोनों approaches fail हो सकती हैं
    Node.js या Python जैसे environments में event loop जितना code संभाल सकता है, उसकी एक सीमा होती है
    मैंने 6~8 लोगों को 200 services manage करते भी देखा है, और 80 लोगों को एक monolith manage करते भी
    microservices छोटे बदलावों के लिए फ़ायदेमंद हैं, लेकिन system-wide changes मुश्किल बनाते हैं
    monolithic architecture इसके उलट है
    आख़िर में अहम architecture नहीं, बल्कि abstraction, testing और decoupling का तरीका है

    • “अगर software एक business problem हल करता है, तो उसे एक ही microservice में बाँधना सही है”
      micro का मानदंड technology नहीं, बल्कि business unit है
      उससे छोटा करोगे तो वह nanoservice बन जाएगा
    • इस तरह का rationalization आख़िरकार runtime की सीमाएँ ढकने वाली अस्थायी जुगाड़ जैसा लगता है
      Beam, JVM, Rust, Go जैसे environments में यह समस्या पहले ही हल हो चुकी है
    • event loop जितना code संभाल सकता है, उसकी सीमा से आपका मतलब ठीक किस unit में है?
      क्या यह CPU cache की समस्या है?
    • क्या large-scale environment में सच में Node.js या Python इस्तेमाल होते हैं?
      मुझे लगा आम तौर पर Go, Java, C# इस्तेमाल होते हैं

  • ज़्यादातर कंपनियों में microservices उल्टा 90% समस्याओं की वजह रहे हैं
    AWS, Google, Netflix जैसी बहुत बड़ी organizations न हों तो यह मॉडल फिट नहीं बैठता
    system को composable units में बाँटना ही पहले से मुश्किल है, उस पर network boundary जोड़ना और भी बेवकूफ़ी है
    लगता है अगला trend React या SPA से हटकर server-centric shift की तरफ़ जाएगा

  • microservices में migration का कारण “tests बार-बार टूट रहे थे” था, यह सुनकर काफ़ी उल्टा approach लगता है
    tests टूटने पर पूरे codebase structure को बदल देना अजीब है

    • हमने भी ऐसा ही issue झेला था, लेकिन हर team को independent development environment देकर इसे हल किया
      team-wise VM और CI/CD settings अलग कर दीं, तो test conflicts गायब हो गए
      कमी यह है कि features के बीच टकराव तुरंत पकड़ में नहीं आते, लेकिन code ownership साफ़ होने से यह बड़ी समस्या नहीं बनी

  • title में [2018] जोड़ने की request थी

    • क्या अब तक वे फिर से microservices की तरफ़ लौट गए, यह जानने की जिज्ञासा है
    • 7 साल पुराने लेख को फिर से ऊपर लाना थोड़ा अजीब लगता है। tech दुनिया में यह लगभग प्राचीन इतिहास है

  • उन्होंने कहा कि “tests टूटते थे तो unrelated code भी बदलना पड़ता था”, इसलिए repo अलग किया गया,
    लेकिन test execution का तरीका बदलना या manual deployment allow करना जैसे दूसरे समाधान भी हो सकते थे
    repo separation ही इकलौता हल नहीं था