2021 में वापस, एक क्लाइंट मेरे पास एक सीधे-सादे ब्रीफ के साथ आया: "हमें एक नीलाम साइट चाहिए। eBay जैसी, लेकिन निशे, क्लासिक मोटरसाइकिल पार्ट्स।" तीन महीने, दो त्यागे गए प्रोटोटाइप्स, और एक वास्तव में शर्मनाक प्रोडक्शन आउटेज के बाद, मेरे पास मत थे। मजबूत मत। हम आख़िरकार वहाँ पहुँचे, लेकिन मैं इसे अब उसी तरह नहीं बनाता। बिल्कुल भी नहीं।
मुख्य बात: 2026 के लिए एक नीलामी प्लेटफॉर्म Next.js, Supabase के साथ रीयल-टाइम चैनलों के लिए लाइव बिडिंग के साथ, और Stripe है; मुश्किल हिस्सा स्टैक नहीं है, बल्कि समवर्ती परिस्थितियों में बिड स्टेट की सत्यता बनाए रखना है।
नीलाम प्लेटफॉर्म धोखे से मुश्किल होते हैं। सतह पर यह बस लिस्टिंग्स, बिड्स, और एक टाइमर है। लेकिन जैसे ही दो यूज़र मिलीसेकंड के अंदर बिड करें, या आपका WebSocket कनेक्शन काउंटडाउन जीरो पर आते ही गिरे, या आपका पेमेंट प्रोसेसर कैप्चर के बीच टाइम आउट हो जाए, तो अचानक आप एक बहुत गुस्से वाले विक्रेता को समझा रहे होते हैं कि उनका 1967 BSA Lightning £12 में क्यों चला गया। तो आइए मैं आपको वॉक करता हूँ कि मैं 2026 में असल में क्या बनाता, टूल दर टूल, फैसला दर फैसला।
---
मुख्य आर्किटेक्चर फैसला: मोनोलिथ या सर्विसेज़?
किसी को पहले वर्जन के लिए माइक्रोसर्विसेज़ पर बेचने दें मत। मुझे मतलब है।
मैंने यह गलती बार-बार देखी है — संस्थापक एक सलाहकार को नियुक्त करता है, सलाहकार एक व्हाइटबोर्ड पर आठ अलग-अलग सर्विसेज़ को डायग्राम करता है, सभी सिर हिलाते हैं, और छह महीने बाद कुछ नहीं शिप होता क्योंकि टीम एक 40 यूज़रों के साथ प्लेटफॉर्म पर इंटर-सर्विस लेटेंसी डीबग कर रही है। एक नीलाम MVP के लिए या यहाँ तक कि मध्यम रूप से स्केल किए गए प्रोडक्ट (कहें, 50,000 से कम मासिक सक्रिय यूज़र), एक मॉड्यूलर मोनोलिथ सही चुनाव है।
मैं जो इस्तेमाल करता: फ्रंटएंड और API लेयर पर Next.js, और Node.js बैकएंड के साथ। सिर्फ इसलिए नहीं कि यह ट्रेंडी है। क्योंकि Next.js 14+ में सर्वर कंपोनेंट्स मॉडल सचमुच नीलाम लिस्टिंग पेजेस की जटिलता को कम करता है जहाँ SEO असल में मायने रखता है, आप चाहते हो वे लॉट विवरण इंडेक्स हों। API रूट्स हल्के काम को सँभालते हैं; भारी रियल-टाइम चीजें कहीं और रहती हैं (एक पल में इस पर और)।
डेटाबेस? PostgreSQL। हमेशा PostgreSQL कुछ भी ट्रांजेक्शनल के लिए। नीलाम गहराई से संबंधपरक हैं — यूज़र्स, लॉट्स, बिड्स, रिज़र्व्स, इनवॉइसेज़ — और आप चाहते हो विदेशी कुंजी कंस्ट्रेंट्स असल काम कर रहे हों, न कि वाइब्स-आधारित एप्लीकेशन लॉजिक। मैं इसे 2026 में Supabase पर चलाता क्योंकि आपको Postgres मिलता है, row-level security, और एक रियल-टाइम सबस्क्रिप्शन लेयर बेक्ड इन, जो जो कभी तीन अलग-अलग इंफ्रास्ट्रक्चर चिंताएँ थीं उन्हें एक बिल में समेट देता है।
---
Real-Time Bidding: वह हिस्सा जो आपको तोड़ देगा
यह वह जगह है जहाँ अधिकांश नीलामी प्लेटफॉर्म मर जाते हैं। या कम से कम लँगड़े हो जाते हैं।
मौलिक समस्या: बिडिंग तुरंत महसूस होनी चाहिए, सुसंगत होनी चाहिए, और race conditions को सही तरीके से सँभालनी चाहिए। अगर दो यूज़र एक ही मिलीसेकंड पर बिड सबमिट करें, तो उनमें से एक जीतता है। डेटाबेस तय करता है कि कौन। फ्रंटएंड नहीं, लोड बैलेंसर नहीं, डेटाबेस, SELECT FOR UPDATE के साथ सही तरीके से लिखे गए ट्रांजेक्शन के माध्यम से।
रियल-टाइम लेयर के लिए, मैं 2026 में कच्चे WebSockets को रोल करने के बजाय Ably का इस्तेमाल करता। मैंने 2022 में Seahawk पर एक संपत्ति नीलाम प्रोजेक्ट पर कच्चा दृष्टिकोण आज़माया, self-hosted socket.io, Redis pub/sub, पूरी बात। यह ठीक था जब तक कि यह नहीं था। Ably आपको गारंटीकृत संदेश क्रम देता है, कनेक्शन स्टेट रिकवरी (तो अगर एक बिडर का फोन नीलाम के बीच WiFi से 4G पर स्विच हो जाए, तो वे चुप-चाप विजयी बिड मिस नहीं करते), और एक समझदारी भरा डैशबोर्ड। स्केल पर प्राइसिंग असल है, लेकिन अधिकांश नीलाम ऑपरेटर्स के लिए यह इंफ्रास्ट्रक्चर जटिलता के मुकाबले शोर है।
"Bid Sniping" समस्या को संभालना
नीलाम sniping, आख़िरी कुछ सेकंड में एक बिड लगाना, आपके क्लाइंट के आधार पर या तो एक विशेषता है या एक कमी है। eBay प्रसिद्धि से इसे अनुमति देता है। कई विशेषज्ञ नीलाम घर अंतिम मिनट में बिड आने पर टाइमर को 30-60 सेकंड तक बढ़ाते हैं। इसे "soft close" या "anti-sniping" लॉजिक कहा जाता है। इसे दिन एक से बनाएँ। नियम सरल है:
- बोली N सेकंड से कम समय बचे आती है
- लेनदेन पुष्टि करता है कि बोली वैध और सर्वोच्च है
- नीलामी समाप्ति समय N सेकंड तक बढ़ता है
- नया समाप्ति समय Ably के माध्यम से सभी जुड़े हुए क्लाइंट्स को प्रसारित होता है
यह शायद 40 लाइनों का सर्वर लॉजिक है। इसे छोड़ना और बाद में लगाना एक सिरदर्दी है जिसे आप नहीं चाहते।
---
भुगतान: चतुर मत बनिए
मैंने देखा है कि लोग नीलाम साइटों पर अजीब-ओ-ग़रीब भुगतान सेटअप के लिए पहुंचते हैं क्योंकि नीलामों की अपनी विचित्र आवश्यकताएं होती हैं—आप भुगतान विवरण पहले से कैप्चर करते हैं, केवल लॉट बंद होने पर चार्ज करते हैं, शायद डिपॉजिट होल्ड करने की जरूरत पड़ सकती है, शायद अगर कोई ऊंची बोली लगा दे तो तुरंत रिफंड करना पड़ सकता है। सब सच है। सब Stripe से सॉल्व करने योग्य है बिना Stripe डॉक्स को छोड़े।
2026 में Stripe अभी भी auction operators के विशाल बहुमत के लिए सही जवाब है। विशेष रूप से:
- standard bid-to-charge flow के लिए Stripe Payment Intents
capture_method: manualएक card को authorize करने के लिए बिना charge किए (deposit holds के लिए आवश्यक)- Stripe Connect अगर आप एक मार्केटप्लेस बना रहे हैं जहाँ कई विक्रेता पेआउट प्राप्त करते हैं
एक चीज़ जो मैं फ्लैग करूंगा: पूरे लॉट वैल्यू के लिए कार्ड को अथॉराइज़ न करें अगर आपके पास कानूनी सलाह न हो कि आपको करना चाहिए। डिपॉजिट के लिए अथॉराइज़ करें (नीलामी की दुनिया में 10-25% आम है), फिर जब लॉट बंद हो तो कैप्चर या वॉयड करें। आपकी कार्ड डिक्लाइन रेट्स आपको धन्यवाद देंगी।
ज्यादा कीमत वाली नीलाम घरों के लिए, क्लासिक कारें, ललित कला, वह तरह की चीजें, आप बैंक ट्रांसफर को सपोर्ट करना चाहेंगे। Stripe अब इसे उनके payment link और invoice प्रोडक्ट्स के जरिए खूब संभाल लेता है, लेकिन आपको रीकॉनसिलिएशन के लिए अभी भी इंसान की जरूरत होगी। इसके लिए एक सिंपल एडमिन क्यू बनाइए; जो ऑटोमेट न होना चाहिए उसे ऑटोमेट मत कीजिए।
---
Search और Filtering: Typesense, Elasticsearch नहीं
ईमानदारी से, नीलामी प्लेटफॉर्म पर सर्च सवाल को कम आँका जाता है। यूज़रों को कैटेगरी, मौजूदा कीमत, बचा हुआ समय, condition, location के आधार पर फ़िल्टर करने की ज़रूरत है। उन्हें इसकी तेज़ी से ज़रूरत है।
Elasticsearch अधिकांश auction sites के लिए overkill है और operate करने में एक सच्ची pain है। Typesense वह है जो मैं उपयोग करूंगा। यह open source है, आप एक $6 DigitalOcean droplet पर self-host कर सकते हैं या Typesense Cloud का उपयोग कर सकते हैं, और search quality catalogue-style data के लिए excellent है। अपने PostgreSQL lots table को Typesense के साथ sync करें एक simple change-data-capture hook के through या हर 30 सेकंड में एक cron job (auction lot prices का real-time sync अच्छा है लेकिन search के लिए शायद ही कभी आवश्यक है)।
एक चीज़ जो Typesense out of the box में अच्छे से हैंडल नहीं करता: collection-only आइटम्स के लिए geosearch। इसमें geo filtering तो है, लेकिन अगर आपकी नीलामी साइट में heavy "local pickup only" इन्वेंटरी है, तो शुरुआत में उस configuration पर आधा दिन खर्च करें। मैंने 2023 में एक garden machinery नीलामी साइट पर नहीं किया, और हमने इसे बाद में दो गुना मेहनत से retrofitted किया।
---
इन्फ्रा और होस्टिंग
यहाँ 2026 के लिए मेरा डिफ़ॉल्ट है:
- Vercel Next.js फ्रंटएंड और API रूट्स के लिए, जीरो कॉन्फिग डिप्लॉयमेंट, हर ब्रांच के लिए प्रिव्यू URL, जहां जरूरत हो edge functions।
- PostgreSQL और auth के लिए Supabase
- WebSockets के लिए Ably
- खोज के लिए Typesense Cloud
- Cloudflare सब कुछ के सामने, फ्री टियर DDoS को हैंडल करता है, इमेज ऑप्टिमाइजेशन, और कैशिंग बिना किसी झंझट के।
- विक्रेता द्वारा अपलोड की गई लॉट इमेजों के लिए Uploadcare या Cloudinary (2026 में अपने सर्वर पर यूजर अपलोड कभी स्टोर न करें, कृपया)
उस स्टैक में Kubernetes नहीं है, कोई self-managed Redis क्लस्टर नहीं, कोई DevOps हायर नहीं। एक सोलो डेवलपर या छोटी टीम इसे चला सकते हैं। और खासतौर पर, यह री-आर्किटेक्ट किए बिना स्केल करता है। Vercel और Supabase ट्रैफिक स्पाइक को हैंडल कर लेंगे जब आप किसी ट्रेड पब्लिकेशन में फीचर हों और 8,000 लोग एक घंटे में आपकी साइट पर आएं।
एक इन्फ्रास्ट्रक्चर गलती जो मैं बार-बार देखता हूँ
लोग बैकग्राउंड जॉब्स को भूल जाते हैं। नीलाम क्लोज इवेंट यूजर-ट्रिगर्ड नहीं होते, वे एक खास टाइमस्टैम्प पर होते हैं, सर्वर-साइड। आपको एक भरोसेमंद जॉब शेड्यूलर चाहिए। मैं 2026 में इसके लिए Inngest यूज करूंगा। यह time-based ट्रिगर्स, रिट्राइज को हैंडल करता है, और आपको एक इवेंट लॉग देता है जो असल में काम आता है जब आप डीबग कर रहे हों "लॉट 447 विजेता को ईमेल भेजे बिना क्यों बंद हुआ"। अपने सर्वर पर सिंपल cron यूज मत कीजिए। जब आपका सर्वर रिस्टार्ट हो, आपकी cron स्टेट गायब हो जाती है।
---
एडमिन और सेलर टूल्स
सेलर्स को लिस्टिंग बनानी होती है, इमेज अपलोड करनी होती हैं, रिजर्व प्राइसेस सेट करने होते हैं, और बिड हिस्ट्री देखनी होती है। बायर्स को विशलिस्ट्स, बिड अलर्ट्स, और इनवॉइस डाउनलोड चाहिए। ये ग्लैमरस फीचर्स नहीं हैं। ये वो हैं जिनके बारे में क्लाइंट्स आपको बुधवार रात 9 बजे फोन करते हैं।
एडमिन पैनल के लिए, मैं Retool के ऊपर हल्का-फुल्का बनाऊंगा या बजट के अनुसार एक custom Next.js डैशबोर्ड। Retool सच में तेजी से सेटअप होता है और नीलाम एडमिन काम का 80% हैंडल करता है—लिस्टिंग को मंजूरी देना, यूजर को मैनेज करना, बिड्स को void करना—बिना ज्यादा कोड लिखे। कुछ भी क्लाइंट-फेसिंग के लिए मैं Next.js में सही तरीके से बनाऊंगा, क्योंकि iframe में Retool embed करना अच्छा यूजर एक्सपेरिएंस नहीं है।
ईमेल नोटिफिकेशन, outbid एलर्ट, लॉट जल्द बंद हो रहा है, इनवॉइस तैयार है, यह सब Resend के जरिए 2026 में। इसने मेरे स्टैक में SendGrid की जगह ली करीब 18 महीने पहले और मैंने पीछे मुड़कर नहीं देखा। डेवलपर एक्सपेरिएंस बहुत बेहतर है और डिलिवेरेबिलिटी ठीक-ठाक रही है।
---
नीलाम के लिए विशेष सुरक्षा विचार
नीलाम प्लेटफॉर्म्स बिड मैनिपुलेशन अटेम्प्ट्स को आकर्षित करते हैं। शिल बिडिंग (एक सेलर अपने लॉट की कीमत को नकली अकाउंट्स का इस्तेमाल करके बढ़ाता है), अकाउंट टेकओवर्स धोखाधड़ी वाली जीतने वाली बिड्स लगाने के लिए, और पेमेंट फ्रॉड सब कुछ रियल हैं और आम ई-कॉमर्स के मुकाबले बेतहाशा ज्यादा आम हैं।
कुछ चीजें हैं जो मैं शुरुआत से ही बेक कर दूंगा:
- बिड सबमिशन पर rate limiting, यूजर के लिए प्रति मिनट प्रति लॉट N बिड्स तक, API लेयर पर लागू। Upstash Redis इसके लिए अच्छा है; इसके पास एक purpose-built rate limiting लाइब्रेरी है।
- बोली लगाने से पहले ईमेल वेरिफिकेशन, यह साफ लगता है, एक चौंकाने वाली मात्रा में दुरुपयोग को रोकता है।
- Stripe Radar के माध्यम से फ्रॉड स्कोरिंग, पहले से ही Stripe में शामिल है, बस इसे इस्तेमाल करो
- संदिग्ध अकाउंट क्लस्टर के लिए IP और डिवाइस फिंगरप्रिंटिंग, FingerprintJS Pro की कीमत सार्थक स्तर पर काम करने के लिए बिल्कुल जायज है
ईमानदारी से कहूँ तो, सबसे महत्वपूर्ण चीज लॉगिंग है। हर बिड अटेम्प्ट, हर फेल हुई पेमेंट, हर अकाउंट एक्शन को लॉग करो। जब कुछ गड़बड़ हो, और होगा ही, तुम्हें एक संपूर्ण ऑडिट ट्रेल चाहिए। Supabase की बिल्ट-इन लॉगिंग के साथ Axiom पर एक हल्का सेटअप यह सब आसानी से कवर कर देता है।
---
FAQ
एक छोटी, स्थानीय नीलामी साइट के लिए न्यूनतम viable stack क्या है?
अगर तुम एक स्थानीय नीलामी घर के लिए बना रहे हो जहाँ शायद 200 उपयोगकर्ता हों और साप्ताहिक बिक्री हो, तो तुम्हें Ably या Typesense की जरूरत नहीं है। Auctions for WooCommerce जैसे प्लगइन वाला WordPress तुम्हें हैरान करने वाली दूरी तक ले जाता है। मैंने इसे क्षेत्रीय नीलाम घरों, प्राचीन वस्तुओं, कृषि उपकरणों के लिए तीन बार सेटअप किया है। जैसे ही तुम्हें लोड के तहत असली समय की प्रतिस्पर्धी बिडिंग चाहिए, तुम इससे तेजी से बाहर निकल जाओ।
क्या मैं Supabase की जगह Firebase का यूज कर सकता हूं?
तुम कर सकते हो। Firebase का Firestore वास्तव में रीयल-टाइम बिड स्टेट के लिए एक उचित विकल्प है। मैं 2026 में Supabase को क्यों पसंद करता हूँ इसका कारण SQL है, नीलामी के डेटा में बहुत संबंधपरक संरचना है (बहुत सारी चीजें बिक्री के हैं, बिडें बहुत और उपयोगकर्ताओं से संबंधित हैं, इनवॉयस बिडों को संदर्भित करते हैं), और दस्तावेज़ डेटाबेस में इसके लिए क्वेरी करना गड़बड़ा जाता है। लेकिन अगर तुम्हारी टीम पहले से Firebase को गहराई से जानती है, तो इसकी खातिर स्विच मत करो।
मैं auction end times के लिए time zones को कैसे handle करूँ?
सब कुछ UTC में स्टोर करें। हमेशा। ब्राउज़र के माध्यम से उपयोगकर्ता के स्थानीय समय क्षेत्र में प्रदर्शित करें। यह स्पष्ट लगता है और मैं अभी भी इसे लगभग एक में पाँच परियोजनाओं में गलत तरीके से किए जाते देखता हूँ। आधुनिक ब्राउज़रों में Intl.DateTimeFormat API बिना किसी लाइब्रेरी के डिस्प्ले साइड को संभालता है।
क्या मुझे एक mobile app की जरूरत है?
MVP के लिए नहीं। पुश नोटिफिकेशन (Web Push API के माध्यम से) के साथ एक अच्छी तरह से बनाया गया प्रगतिशील वेब ऐप बोलीदाताओं को मोबाइल पर जो कुछ भी चाहिए उसका 90% कवर करता है। नेटिव ऐप्स बाद में आते हैं, अगर व्यवसाय इसे सही ठहराता है। जब वह दिन आए तो मैं Expo और React Native का उपयोग करूँगा, iOS और Android में साझा कोडबेस, और टीम पहले से ही React जानती है।
---
नीलामी को ऑनलाइन चलाना एक वैध इंजीनियरिंग चुनौती है जो धोखाधड़ी से सरल यूजर इंटरफेस में तैयार की गई है। बिडिंग इंटरफेस तीन बटन और एक नंबर है। इसके नीचे सब कुछ, सुसंगतता, न्यायसंगतता, रीयल-टाइम स्टेट, धोखाधड़ी रोकथाम, वह जगह है जहाँ असली काम रहता है। शुरुआत से ही स्टैक को सही तरीके से सेट करो और बाकी सब केवल फीचर हैं। इसे गलत करो और तुम वह व्यक्ति हो जो विक्रेता को समझा रहे हो कि उनकी वस्तु £12 में क्यों बिक गई।
Boring infrastructure build करो। Interesting products उसके ऊपर build करो।