Key Takeaways
- मौजूदा सिस्टम को पूरी तरह बदले बिना, क्रमिक decoupling के ज़रिए परिवर्तन को आगे बढ़ाया गया।
- CDC-आधारित real-time data system ने mainframe तक direct access की जगह ली।
- REST की बजाय GraphQL अपनाकर कई BFF layers हटाई गईं और flexibility व maintainability हासिल की गई।
- domain-केंद्रित team structure (Team Topologies) के ज़रिए टीमों की responsibility और ownership को स्पष्ट किया गया।
- क्रमिक deployment और automation के माध्यम से बिना जोखिम के सिस्टम बदला गया और स्थिर रूप से value deliver की गई।
परिचय केस: outage के दौरान भी जीवित रहा आधा सिस्टम
mainframe outage हुआ, लेकिन cloud-आधारित streaming architecture की वजह से नया UI सामान्य रूप से चलता रहा।
पुराना सिस्टम down होने पर भी नया सिस्टम customer experience बनाए रख सका और अपनी resilience साबित की।
मुख्य रणनीति: बहु-स्तरीय decoupling
- Domain-Driven Design (DDD): mainframe-केंद्रित मॉडल को business-friendly रूप में फिर से बनाया गया
- Team Topologies: function-केंद्रित team organization में परिवर्तन
- event-driven architecture: asynchronous तरीके से सिस्टमों के बीच coupling कम की गई
- Change Data Capture (CDC): real-time data changes को पकड़कर legacy और नए सिस्टम को जोड़ा गया
पुरानी संरचना: Unified Web Portal 1.0
विभिन्न mainframe data को ETL से एकीकृत करके SQL DB और SaaS में उपलब्ध कराया गया,
लेकिन real-time क्षमता की कमी, data quality में गिरावट, और direct mainframe calls जैसी समस्याएँ पैदा हुईं।
समस्याएँ
- ETL के कारण data delay
- mainframe के साथ non-elastic synchronous connection
- बहुत बड़ी संख्या में BFF API बनना
- organizational structure के कारण bottleneck और release delay
- traffic spike के समय mainframe overload से पूरी service outage
नए लक्ष्य तय करना
तकनीकी लक्ष्य: mainframe और web को अलग करना, BFF हटाना, टीम autonomy सुनिश्चित करना
business लक्ष्य: call center inquiries कम करना, license cost घटाना, customer satisfaction बढ़ाना
नई architecture का overview
- mainframe अभी भी system of record है
- CDC → Kafka → domain DB (CosmosDB)
- GraphQL + REST API → BFF → UI
- event-driven structure और message broker से सभी components जुड़े
Step 1: Change Data Capture
- real-time data streaming से system of reference बनाया गया
- mainframe → Kafka → transformation → domain DB → API के रूप में उपलब्ध
- mainframe schema पर निर्भर न रहने वाली flexible data structure हासिल की गई
Step 2: Domain-Driven Design + GraphQL
- DDD से domain model परिभाषित किया गया (Entity, Command, Event)
- हर domain को GraphQL node के रूप में बनाया गया, schema stitching के माध्यम से supergraph तैयार किया गया
- केवल आवश्यक data query करने वाली optimized query structure का समर्थन
organizational structure में बदलाव: Team Topologies
- function-केंद्रित stream-aligned teams में पुनर्गठन
- complex areas (जैसे mainframe integration) को dedicated team ने संभाला
- technical support के लिए Enablement team चलाई गई
event-driven विस्तार: internal domain events + saga pattern
- Outbox pattern के माध्यम से domain change पर events उत्पन्न किए गए
- Parallel Saga से mainframe tasks और CDC को synchronize किया गया
- state machine-आधारित workflow बनाया गया → complex flow का भी समर्थन
चुनौतियाँ
- event-driven structure को अपनाने के लिए organization के भीतर mindset change की ज़रूरत
- asynchronous structure के कारण observability सुनिश्चित करना अनिवार्य
- mainframe batch jobs → CDC pipeline overload का कारण
- GraphQL schema management की complexity और federated approach अपनाने पर विचार
- authentication/logging जैसे common concerns को अलग package और automation से manage किया गया
release strategy: release train + Feature Flag
- हर team ने independently deploy किया, और deployment repository में integration किया गया
- Kustomize से environment-specific deployment pipeline बनाई गई
- feature flags से feature/security releases अलग किए गए, और trunk-based development बनाए रखा गया
hybrid architecture का उपयोग
- UWP 1.0 और UWP 2.0 को साथ चलाते हुए क्रमिक परिवर्तन किया गया
- edge routing से user requests को धीरे-धीरे नए सिस्टम की ओर मोड़ा गया
निष्कर्ष: एक evolvable platform का निर्माण
- frontend और mainframe का पूर्ण decoupling
- team-केंद्रित structure से speed और stability हासिल
- customer satisfaction और operating cost में सुधार
- भविष्य में mainframe replacement तक संभव बनाने वाली flexible foundation तैयार
1 टिप्पणियां
क्रमिक सुधार और क्रमिक microservice extraction बहुत महत्वपूर्ण हैं... ऐसे लेख देखकर लगता है कि उस प्रोजेक्ट को लीड करने वाला PM वास्तव में बहुत महत्वपूर्ण और कमाल का है। इतनी सारी चीज़ों को मैनेज करना, वाह।