API, इंटीग्रेशन, ऑटोमेशन, अवलोकनयोग्य सिस्टम।
कोई सिमुलेटेड डेटा नहीं, कोई खिलौना प्रोजेक्ट नहीं।
मैंने जल्दी ही उन सिस्टम्स को छेड़ना शुरू कर दिया था जो उस समय मेरे स्तर से बड़े थे। जब मेरे आसपास कई लोग बेसिक CRUD लिख रहे थे, मैं इस बात पर अटका हुआ था कि एक असली प्रोडक्ट के पीछे वाकई क्या होता है: queues, caches, concurrency, deployments, sockets, infrastructure। मोड़ वह दिन था जब मैंने बैकएंड को «बस APIs बनाना» समझना छोड़ा और उसे ऐसी सिस्टम डिज़ाइन करने का काम मानना शुरू किया जो असली उपयोग में टूटें नहीं। उस पल से मैं पूरी तरह से इसमें खिंच गया।
मैंने जो भी जाना, उसका बड़ा हिस्सा चीज़ें तोड़ने से आया। डिप्लॉय जो पूरी सर्विस गिरा दें, ख़राब कॉन्फ़िगर्ड प्रॉक्सी, ऐसे concurrency bugs जिन्हें दोबारा बनाना नामुमकिन था, जल्दी में की गई PostgreSQL माइग्रेशन, प्रोडक्शन में बेतुके रीडायरेक्ट फेंकता हुआ middleware। ठीक वहीं मैंने सबसे ज़्यादा सीखा। मुझे समझ आया कि सुंदर इंटरफ़ेस बनाने से कहीं ज़्यादा मुझे जटिल सिस्टम्स को डिबग करना और असली बॉटलनेक्स ढूँढना अच्छा लगता है। यह समझ पाना कि कोई चीज़ निचले स्तर पर क्यों फेल होती है और उसे सलीक़े से ठीक करना, यही वह क्षण है जब मैं फ्लो के सबसे क़रीब होता हूँ।
समय के साथ मेरे प्रोजेक्ट असली आर्किटेक्चर के काम की ओर मुड़ गए: ऑटोमेटेड पाइपलाइन्स, रीयल-टाइम SSE, मल्टी-सर्विस Docker स्टैक्स, nginx के रिवर्स प्रॉक्सी, स्क्रैपिंग और ट्रेंड सिस्टम्स, कंटेंट ऑटोमेशन, इंटरनल टूलिंग। मुझे «जेनेरिक ऐप्स» में कभी ज़्यादा रुचि नहीं रही। मैं उन प्रोडक्ट्स के लिए उपयोगी, तेज़ और स्थिर इन्फ्रास्ट्रक्चर बनाना चाहता हूँ जो असल में चलते हैं।
यह सूची वह है जिनकी ओर मैं सबसे पहले हाथ बढ़ाता हूँ, झेलने वाले टूल्स नहीं। यह प्रोडक्शन में सालों के घिसाव से चुनी गई है, घोषणाओं को पढ़कर नहीं।
कुछ ही असली सिस्टम्स, हर एक असली उपयोगकर्ता आधार के लिए लाइव। अधूरी डेमो का पोर्टफोलियो नहीं।
मल्टी-टेनेंट पब्लिशिंग प्लेटफ़ॉर्म, जो 11 ट्रेंड स्रोतों को ट्रैक करता है, अवसर का स्कोर करता है, लेख तैयार और समीक्षा करता है, और 12 भाषाओं में 13 niche साइट्स पर भेजता है। Postgres, pg-boss workers, Claude इंटीग्रेशन, अपनी QA पाइपलाइन्स, और हर क्यू का live tail दिखाने वाला डैशबोर्ड।
kramaru.essmart take-profit, hourly gates और circuit breakers के साथ 24/7 चलती चार polyvps strategies। असली पैसा, बैकटेस्ट नहीं। डेली मेट्रिक्स डैशबोर्ड, kill-switch, हर एंट्री का audit log।
OpenFootball के ऊपर Sofascore enrichment के साथ फ़ुटबॉल pick settlement engine, हर कंटेनर पर हार्डनिंग वाले Docker स्टैक से जुड़ा। NGINX, Postfix, पुरानी घटना के बाद header-replay हमलों से बचाने के लिए Server Actions encryption keys स्थिर किए गए।
Flutter Desktop POS, Node बैकएंड, MySQL, थर्मल प्रिंटिंग, WhatsApp इंटीग्रेशन। असली ग्राहक, ऑफ़लाइन-फ़र्स्ट।
mkir.es पर सार्वजनिक डेमो: एक अकेला .NET 8 प्रोसेस Server-Sent Events से डेटाबेस के बदलावों को कई ब्राउज़र तक फ़ैन-आउट करता है। क्लाइंट पर कोई डिपेंडेंसी नहीं, सादा HTML जो Postgres triggers को सीधे रेंडर करता है।
mkir.esजिस प्रोजेक्ट को मैं आमतौर पर एक वाक्य में समेट देता हूँ, उसका लंबा संस्करण। मुश्किल फ़ैसले, जो चीज़ें मैंने तोड़ीं, और जो असल में लाइव है।
TopSec इसलिए मौजूद है ताकि वह विशाल इन्फ्रास्ट्रक्चर या प्रोडक्ट के लिए ज़रूरत से बहुत भारी स्टैक्स पर निर्भर हुए बिना डेटा को रीयल-टाइम में एकत्र, सिंक और विज़ुअलाइज़ कर सके। ब्रीफ कहने में सरल था, बनाने में कठिन: कई सर्विसें एक साथ बात करते हुए भी डेटा को जीवंत, तेज़ और सुसंगत बनाए रखना।
.NET 8 बैकएंड में क्या रहेगा और Next.js से क्या हल होगा, इसके बीच साफ़ रेखा खींचना। एक सूक्ष्म मामले ने यह रेखा स्पष्ट कर दी: /api routes और next-intl middleware मिलकर /es/api/* की ओर 307 redirects बना रहे थे। तकनीकी रूप से सही, व्यवहार में टूटा हुआ। कुछ locales पर realtime और stats endpoints चुपचाप फेल हो रहे थे।
जो patch आपसे कोई नहीं माँगता, वही engineer rate को न्यायसंगत ठहराता है: redirect rules एक-एक करके ठीक करने के बजाय, मैंने middleware matcher को फिर से लिखकर /api को पूरी तरह से बाहर कर दिया। देखने में छोटा परिवर्तन, आर्किटेक्चरली बहुत बड़ा।
बहुत जल्दी optimise करना ख़राब है। पहले दिन से performance को नज़रअंदाज़ करना उससे भी ख़राब। कार्य सिद्धांत
दूसरा फ़ैसला PostgreSQL को सच्चाई का एकमात्र स्रोत बनाए रखना था। इस प्रोडक्ट के लिए consistency और जटिल queries लिखने की क्षमता, NoSQL store से निचोड़ी जा सकने वाली किसी भी speed gain से ज़्यादा क़ीमती थी। उबाऊ ठीक है, जब उबाऊ सही है।
एक बार production इसलिए गिरा क्योंकि मैंने मान लिया कि एक Docker image वाक़ई फिर से बनी है। «नया» कोड पुरानी जैसा ही व्यवहार कर रहा था। असली अपराधी था npm ci जो package-lock न होने पर चुपचाप फेल हो रहा था और build को असंगत छोड़ रहा था। मैंने application logic डिबग करने में घंटों गँवाए, जबकि असली समस्या pipeline में थी।
Twitter पर नहीं, production incidents से कमाई गई मज़बूत स्थितियाँ। अगर इनमें से कोई आपको कसता है, तो शायद हम साथ बढ़िया चलेंगे।
«नहीं» कहना ही «हाँ» को भरोसेमंद बनाता है। ये वे प्रोजेक्ट हैं जिनके लिए मैं सही व्यक्ति नहीं हूँ।
2022 से freelance और contracting कर रहा हूँ। Remote-first भूमिकाओं के लिए खुला हूँ, या Málaga और Costa del Sol में hybrid के लिए जब प्रोजेक्ट सफ़र की क़ीमत चुकाए। ऐसे बहुत corporate माहौल में रुचि नहीं जहाँ engineering प्रोसेस के नीचे ग़ायब हो जाए।
Email सबसे जल्दी जवाब देता है। गर्म परिचय LinkedIn से, कोड GitHub पर।