2021 में, एक क्लाइंट मेरे पास एक सीधी-सादी ब्रीफ के साथ आया था: "हमें एक नीलाम साइट चाहिए। ईबे जैसी, लेकिन विशेष — क्लासिक मोटरसाइकिल पार्ट्स।" तीन महीने, दो छोड़े गए प्रोटोटाइप, और एक सच में शर्मनाक प्रोडक्शन आउटेज के बाद, मेरे पास राय थी। बहुत मजबूत राय। हम आखिर में वहाँ पहुँचे, लेकिन मैं इसे अब उसी तरह नहीं बनाऊंगा। बिल्कुल नहीं।
नीलाम प्लेटफॉर्म धोखे से मुश्किल होते हैं। सतह पर यह बस लिस्टिंग्स, बिड्स, और एक टाइमर है। लेकिन जैसे ही दो यूजर्स मिलीसेकंड के भीतर बिड करें, या आपका WebSocket कनेक्शन ठीक उस समय खट्टा हो जब काउंटडाउन शून्य पर पहुँचे, या आपका पेमेंट प्रोसेसर कैप्चर के बीच में टाइम आउट हो जाए — अचानक आप एक बहुत ही गुस्से वाले विक्रेता को समझा रहे हैं कि उनका 1967 BSA Lightning £12 में क्यों चला गया। तो चलिए मैं आपको यह बताता हूँ कि मैं 2026 में वास्तव में क्या बनाऊंगा, टूल दर टूल, फैसले दर फैसले।
---
मुख्य आर्किटेक्चर फैसला: मोनोलिथ या सर्विसेज़?
किसी को पहले वर्जन के लिए माइक्रोसर्विसेज़ पर बेचने दें मत। मुझे मतलब है।
मैंने यह गलती बार-बार देखी है — संस्थापक एक सलाहकार नियुक्त करता है, सलाहकार व्हाइटबोर्ड पर आठ अलग-अलग सेवाएँ बनाता है, सभी सिर स्पंदन करते हैं, और छह महीने बाद कुछ भी लॉन्च नहीं होता क्योंकि टीम 40 उपयोगकर्ताओं वाले प्लेटफॉर्म पर इंटर-सर्विस लेटेंसी को डीबग कर रही है। नीलामी एमवीपी के लिए या यहाँ तक कि मध्यम स्तर पर स्केल किए गए उत्पाद के लिए (मान लीजिए, 50,000 से कम मासिक सक्रिय उपयोगकर्ता), एक मॉड्यूलर मोनोलिथ सही विकल्प है।modular monolithis the right call.
मैं क्या चुनूँगा: फ्रंटएंड और API लेयर के लिए Next.js, और Node.js बैकएंड के साथ। ट्रेंडी होने के कारण नहीं। क्योंकि Next.js 14+ में सर्वर कंपोनेंट मॉडल वास्तव में नीलामी सूची पृष्ठों की जटिलता को कम करता है जहाँ SEO वास्तव में मायने रखता है — आप चाहते हैं कि वह lot विवरण इंडेक्स हों। API रूट हल्के-फुल्के काम को संभालते हैं; भारी वास्तविक समय का सामान कहीं और रहता है (इसके बारे में एक पल में विस्तार से बताऊँगा)।Next.json the frontend and API layer, with a Node.js backend. Not because it's trendy. Because the server components model in Next.js 14+ genuinely reduces the complexity of auction listing pages where SEO actually matters — you want those lot descriptions indexed. The API routes handle lighter lifting; the heavy real-time stuff lives elsewhere (more on that in a moment).
डेटाबेस? PostgreSQL। हमेशा PostgreSQL किसी भी लेनदेन योग्य चीज़ के लिए। नीलामियाँ गहराई से संबंधपरक हैं — उपयोगकर्ता, lots, बोलियाँ, रिज़र्व, चालान — और आप विदेशी कुंजी प्रतिबंधों को वास्तविक काम करते हुए देखना चाहते हैं, न कि vibes-आधारित एप्लिकेशन लॉजिक। मैं इसे 2026 में Supabase पर चलाऊँगा क्योंकि आपको Postgres, row-level सुरक्षा, और एक real-time सदस्यता लेयर मिल जाता है जो बिल्ट-इन होता है, जो उस चीज़ को जो पहले तीन अलग-अलग इंफ्रास्ट्रक्चर समस्याएँ हुआ करती थीं, एक बिल में समेट देता है।Supabasein 2026 because you get Postgres, row-level security, and a real-time subscription layer baked in, which collapses what used to be three separate infrastructure concerns into one bill.
---
Real-Time Bidding: वह हिस्सा जो आपको तोड़ देगा
यह वह जगह है जहाँ अधिकांश नीलामी प्लेटफॉर्म मर जाते हैं। या कम से कम लँगड़े हो जाते हैं।
मूलभूत समस्या: बोली तत्काल महसूस करनी चाहिए, सुसंगत होनी चाहिए, और race conditions को सही तरीके से संभालना चाहिए। अगर दो उपयोगकर्ता एक ही मिलीसेकंड में बोली जमा करते हैं, तो उनमें से एक जीतता है। डेटाबेस फैसला करता है कि कौन। फ्रंटएंड नहीं, load balancer नहीं — डेटाबेस, SELECT FOR UPDATE के साथ सही तरीके से लिखे गए लेनदेन के माध्यम से।SELECT FOR UPDATE.
real-time लेयर के लिए, मैं 2026 में Ably का उपयोग करूँगा, raw WebSockets को रोल करने के बजाय। मैंने 2022 में Seahawk पर एक संपत्ति नीलामी प्रोजेक्ट पर raw दृष्टिकोण का प्रयास किया — self-hosted socket.io, Redis pub/sub, सब कुछ। जब तक कि ऐसा न हो, यह ठीक था। Ably आपको गारंटीकृत संदेश क्रमबद्धता, कनेक्शन स्टेट रिकवरी देता है (इसलिए अगर किसी बोली लगाने वाले का फोन नीलामी के बीच WiFi से 4G पर स्विच करता है, तो वह चुप चाप जीती हुई बोली को मिस नहीं करता), और एक समझदारीपूर्ण डैशबोर्ड। बड़े पैमाने पर कीमत वास्तविक है, लेकिन अधिकांश नीलामी ऑपरेटरों के लिए यह इंफ्रास्ट्रक्चर जटिलता के मुकाबले शोर है।Ablyin 2026 rather than rolling raw WebSockets. I tried the raw approach on a property auction project at Seahawk back in 2022 — self-hosted socket.io, Redis pub/sub, the works. It was fine until it wasn't. Ably gives you guaranteed message ordering, connection state recovery (so if a bidder's phone switches from WiFi to 4G mid-auction, they don't silently miss the winning bid), and a sensible dashboard. The pricing at scale is real, but for most auction operators it's noise compared to infrastructure complexity.
"Bid Sniping" समस्या को संभालना
नीलामी sniping — अंतिम कुछ सेकंड में बोली लगाना — आपके क्लाइंट के आधार पर एक विशेषता या बग है। eBay प्रसिद्ध रूप से इसे अनुमति देता है। कई विशेषज्ञ नीलामी घरानों को अगर अंतिम मिनट में कोई बोली आए तो टाइमर को 30–60 सेकंड तक बढ़ाते हैं। इसे "soft close" या "anti-sniping" लॉजिक कहा जाता है। इसे पहले दिन से ही बनाएँ। नियम सरल है:
- बोली N सेकंड से कम समय बचे आती है
- लेनदेन पुष्टि करता है कि बोली वैध और सर्वोच्च है
- नीलामी समाप्ति समय N सेकंड तक बढ़ता है
- नया समाप्ति समय Ably के माध्यम से सभी जुड़े हुए क्लाइंट्स को प्रसारित होता है
यह शायद 40 लाइनों का सर्वर लॉजिक है। इसे छोड़ना और बाद में लगाना एक सिरदर्दी है जिसे आप नहीं चाहते।
---
भुगतान: चतुर मत बनिए
मैंने लोगों को नीलामी साइट्स पर विदेशी भुगतान सेटअप के लिए पहुंचते हुए देखा है क्योंकि नीलामियों की अजीब आवश्यकताएं होती हैं — आप अग्रिम में भुगतान विवरण कैप्चर करते हैं, केवल जब लॉट बंद होता है तो चार्ज करते हैं, जमा को होल्ड करने की जरूरत हो सकती है, यदि आप आगे निकल जाएं तो तुरंत रिफंड करने की जरूरत हो सकती है। सब सच है। सब Stripe से समाधान योग्य है Stripe डॉक्स छोड़े बिना।
2026 में Stripe अभी भी नीलामी ऑपरेटरों के विशाल बहुमत के लिए सही उत्तर है। विशेष रूप से:in 2026 is still the right answer for the vast majority of auction operators. Specifically:
- Stripe Payment Intents मानक बोली-से-चार्ज प्रवाह के लिएfor the standard bid-to-charge flow
capture_method: मैनुअल — कार्ड को चार्ज किए बिना अधिकृत करना (डिपोज़िट होल्ड के लिए आवश्यक)to authorise a card without charging it (essential for deposit holds)- Stripe Connect अगर आप एक मार्केटप्लेस बना रहे हैं जहाँ कई विक्रेता पेआउट प्राप्त करते हैं
एक चीज़ जो मैं फ्लैग करूँ: शुरुआत में पूरी लॉट वैल्यू के लिए कार्ड को अधिकृत न करें जब तक कानूनी सलाह न हो। डिपोज़िट के लिए अधिकृत करें (नीलामी की दुनिया में 10–25% आम है), फिर लॉट बंद होने के बाद कैप्चर या वॉइड करें। आपकी कार्ड डिक्लाइन रेट इसके लिए आपको धन्यवाद देगी।
ज़्यादा वैल्यू वाले नीलामी घरों के लिए — क्लासिक कार, फाइन आर्ट, इस तरह की चीज़ें — आपको बैंक ट्रांसफर के लिए जगह देनी होगी। Stripe अब इसे उनके payment link और invoice प्रोडक्ट के माध्यम से काफी अच्छे से हैंडल करता है, लेकिन reconciliation के लिए आपको अभी भी एक इंसान की ज़रूरत होगी। इसके लिए एक सिंपल admin queue बनाएँ; जो चीज़ें ऑटोमेट करने की ज़रूरत नहीं है उन्हें ऑटोमेट न करें।
---
Search और Filtering: Typesense, Elasticsearch नहीं
ईमानदारी से, नीलामी प्लेटफॉर्म पर सर्च सवाल को कम आँका जाता है। यूज़रों को कैटेगरी, मौजूदा कीमत, बचा हुआ समय, condition, location के आधार पर फ़िल्टर करने की ज़रूरत है। उन्हें इसकी तेज़ी से ज़रूरत है।
Elasticsearch ज़्यादातर नीलामी साइटों के लिए ओवरकिल है और ऑपरेट करने में असली परेशानी है। Typesense वह है जो मैं इस्तेमाल करूँ। यह open source है, आप इसे $6 DigitalOcean droplet पर self-host कर सकते हैं या Typesense Cloud इस्तेमाल कर सकते हैं, और catalogue-style डेटा के लिए सर्च क्वालिटी excellent है। अपने PostgreSQL lots टेबल को Typesense में sync करें एक सिंपल change-data-capture hook के माध्यम से या हर 30 सेकंड में एक cron जॉब के माध्यम से (नीलामी लॉट कीमतों का real-time sync बहुत अच्छा है लेकिन सर्च के लिए शायद ही कभी ज़रूरी है)।Typesenseis what I'd use. It's open source, you can self-host on a $6 DigitalOcean droplet or use Typesense Cloud, and the search quality is excellent for catalogue-style data. Sync your PostgreSQL lots table to Typesense via a simple change-data-capture hook or a cron job every 30 seconds (real-time sync of auction lot prices is nice but rarely necessary for search).
एक चीज़ जो Typesense out of the box में अच्छे से हैंडल नहीं करता: collection-only आइटम्स के लिए geosearch। इसमें geo filtering तो है, लेकिन अगर आपकी नीलामी साइट में heavy "local pickup only" इन्वेंटरी है, तो शुरुआत में उस configuration पर आधा दिन खर्च करें। मैंने 2023 में एक garden machinery नीलामी साइट पर नहीं किया, और हमने इसे बाद में दो गुना मेहनत से retrofitted किया।
---
इन्फ्रा और होस्टिंग
यहाँ 2026 के लिए मेरा डिफ़ॉल्ट है:
- Next.js फ्रंटएंड और API रूट्स के लिए Vercel — ज़ीरो कॉन्फ़िग डिप्लॉयमेंट, हर ब्रांच के लिए प्रीव्यू URL, जहाँ चाहिए वहाँ edge functionsfor the Next.js frontend and API routes — zero config deployments, preview URLs per branch, edge functions where needed
- PostgreSQL और auth के लिए Supabasefor PostgreSQL and auth
- WebSockets के लिए Ablyfor WebSockets
- सर्च के लिए Typesense Cloudfor search
- सबकुछ के आगे Cloudflare — फ्री टियर बिना किसी परेशानी के DDoS, इमेज ऑप्टिमाइज़ेशन और कैशिंग को संभालता हैin front of everything — free tier handles DDoS, image optimisation, and caching without fuss
- विक्रेता द्वारा अपलोड की गई लॉट इमेज के लिए Uploadcare या Cloudinary (2026 में कृपया अपने सर्वर पर यूजर अपलोड कभी स्टोर न करें)orCloudinaryfor seller-uploaded lot images (never store user uploads on your own server in 2026, please)
इस स्टैक में कोई Kubernetes नहीं, कोई self-managed Redis cluster नहीं, कोई DevOps हायर नहीं। एक solo developer या छोटी टीम इसे चला सकती है। और महत्वपूर्ण बात — यह re-architect किए बिना स्केल करता है। जब आप किसी ट्रेड पब्लिकेशन में featured हों और एक घंटे में 8,000 लोग आपकी साइट को हिट करें, तो Vercel और Supabase ट्रैफिक स्पाइक को संभाल लेंगे।
एक इन्फ्रास्ट्रक्चर गलती जो मैं बार-बार देखता हूँ
लोग बैकग्राउंड जॉब्स को भूल जाते हैं। नीलाम बंद होने की घटनाएं यूजर द्वारा ट्रिगर नहीं होती — ये एक विशिष्ट टाइमस्टैम्प पर, सर्वर-साइड होती हैं। आपको एक विश्वसनीय जॉब शेड्यूलर की जरूरत है। मैं 2026 में इसके लिए Inngest का इस्तेमाल करूंगा। यह टाइम-बेस्ड ट्रिगर्स को हैंडल करता है, रिट्राइज करता है, और आपको एक इवेंट लॉग देता है जो तब वाकई उपयोगी होता है जब आप डीबग कर रहे हों कि "लॉट 447 विजेता को ईमेल भेजे बिना बंद क्यों हुआ"। अपने सर्वर पर सिर्फ cron मत लगाइए। जब आपका सर्वर रीस्टार्ट हो, आपकी cron स्टेट चली जाएगी।Inngestfor this in 2026. It handles time-based triggers, retries, and gives you an event log that's actually useful when you're debugging "why did lot 447 close without sending the winner email". Don't use a simplecronon your server. When your server restarts, your cron state is gone.
---
एडमिन और सेलर टूल्स
सेलर्स को लिस्टिंग बनानी होती है, इमेज अपलोड करनी होती हैं, रिजर्व प्राइसेस सेट करने होते हैं, और बिड हिस्ट्री देखनी होती है। बायर्स को विशलिस्ट्स, बिड अलर्ट्स, और इनवॉइस डाउनलोड चाहिए। ये ग्लैमरस फीचर्स नहीं हैं। ये वो हैं जिनके बारे में क्लाइंट्स आपको बुधवार रात 9 बजे फोन करते हैं।
एडमिन पैनल के लिए, मैं Retool के ऊपर हल्के-फुल्के तरीके से बिल्ड करूंगा या बजट के हिसाब से कस्टम Next.js डैशबोर्ड बनाऊंगा। Retool सचमुच में फास्ट है सेट करने के लिए और नीलाम एडमिन टास्क्स के 80% को हैंडल करता है — लिस्टिंग्स को अप्रूव करना, यूजर्स को मैनेज करना, बिड्स को वॉइड करना — ज्यादा कोड लिखे बिना। किसी भी क्लाइंट-फेसिंग चीज के लिए मैं Next.js में सही तरीके से बिल्ड करूंगा, क्योंकि iframe में एम्बेड किया गया Retool अच्छा यूजर एक्सपीरिएंस नहीं है।Retoolor a custom Next.js dashboard depending on budget. Retool is genuinely fast to stand up and handles the 80% of auction admin tasks — approving listings, managing users, voiding bids — without writing much code. For anything client-facing I'd build properly in Next.js, because Retool embedded in an iframe is not a good user experience.
ईमेल नोटिफिकेशन्स — आउटबिड अलर्ट्स, लॉट जल्दी बंद होने वाली है, इनवॉइस तैयार है — 2026 में Resend के जरिए जाती हैं। इसने लगभग 18 महीने पहले मेरे स्टैक में SendGrid की जगह ली और मैंने फिर पीछे मुड़कर नहीं देखा। डेवलपर एक्सपीरिएंस खासतौर पर बेहतर है और डिलिवरेबिलिटी सॉलिड रही है।Resendin 2026. It replaced SendGrid in my stack about 18 months ago and I haven't looked back. The developer experience is notably better and the deliverability has been solid.
---
नीलाम के लिए विशेष सुरक्षा विचार
नीलाम प्लेटफॉर्म्स बिड मैनिपुलेशन अटेम्प्ट्स को आकर्षित करते हैं। शिल बिडिंग (एक सेलर अपने लॉट की कीमत को नकली अकाउंट्स का इस्तेमाल करके बढ़ाता है), अकाउंट टेकओवर्स धोखाधड़ी वाली जीतने वाली बिड्स लगाने के लिए, और पेमेंट फ्रॉड सब कुछ रियल हैं और आम ई-कॉमर्स के मुकाबले बेतहाशा ज्यादा आम हैं।
कुछ चीजें हैं जो मैं शुरुआत से ही बेक कर दूंगा:
- बिड सबमिशन पर रेट लिमिटिंग — प्रति यूजर प्रति मिनट प्रति लॉट अधिकतम N बिड्स, API लेयर पर लागू किया गया। Upstash Redis इसके लिए बढ़िया है; इसके पास एक purpose-built rate limiting library है।— max N bids per user per minute per lot, enforced at the API layer. Upstash Redis is good for this; it has a purpose-built rate limiting library.
- बिडिंग की अनुमति से पहले ईमेल वेरिफिकेशन — स्पष्ट लगता है, लेकिन काफी मात्रा में दुरुपयोग को रोकता है— sounds obvious, stops a surprising amount of abuse
- Stripe Radar के जरिए फ्रॉड स्कोरिंग — पहले से ही Stripe में शामिल है, बस इसे यूज करें— already included in Stripe, just use it
- संदिग्ध अकाउंट क्लस्टर के लिए IP और डिवाइस फिंगरप्रिंटिंग — FingerprintJS Pro लागत के लायक है अगर आप किसी सार्थक स्केल पर काम कर रहे हैं—FingerprintJS Prois worth the cost if you're operating at any meaningful scale
ईमानदारी से कहूं तो, सबसे महत्वपूर्ण चीज़ लॉगिंग है। हर बिड अटेम्प्ट को लॉग करें, हर विफल पेमेंट को, हर अकाउंट एक्शन को। जब कुछ गलत होता है — और होगा — आप एक पूर्ण ऑडिट ट्रेल चाहते हैं। Supabase की built-in logging प्लस Axiom पर एक lightweight setup बिना ज्यादा मेहनत के इसे कवर कर देता है।Axiomcovers this without much effort.
---
FAQ
एक छोटी, स्थानीय नीलामी साइट के लिए न्यूनतम viable stack क्या है?
अगर आप एक स्थानीय नीलामी घर के लिए बना रहे हैं जहां शायद 200 यूजर्स हों और साप्ताहिक बिक्री हो, तो आपको Ably या Typesense की ज़रूरत नहीं है। Auctions for WooCommerce जैसी प्लगइन के साथ WordPress आपको हैरान करने वाली हद तक आगे ले जाता है। मैंने इनमें से तीन regional auction houses के लिए सेटअप किए हैं — antiques, farm equipment, उस तरह की चीजें। जैसे ही आपको लोड के तहत real-time competitive bidding की ज़रूरत हो, तुरंत आगे बढ़ जाएं।Auctions for WooCommercegets you surprisingly far. I've set up three of these for regional auction houses — antiques, farm equipment, that sort of thing. The moment you need real-time competitive bidding under load, outgrow it fast.
क्या मैं Supabase की जगह Firebase का यूज कर सकता हूं?
आप कर सकते हैं। Firebase का Firestore असल में real-time bid state के लिए एक उचित विकल्प है। 2026 में मैं Supabase को ज्यादा पसंद करता हूँ SQL की वजह से — auction data में बहुत सारी relational structure होती है (lots sales से संबंधित होते हैं, bids lots और users से संबंधित होते हैं, invoices bids को reference करते हैं), और document database को इसके लिए query करना messy हो जाता है। लेकिन अगर आपकी टीम पहले से Firebase को गहराई से जानती है, तो सिर्फ इसी वजह से switch मत करो।
मैं auction end times के लिए time zones को कैसे handle करूँ?
सब कुछ UTC में store करो। हमेशा। Browser के द्वारा user के local time zone में display करो। यह obvious लगता है और मैं इसे अभी भी लगभग एक में से पाँच projects में गलत देखता हूँ। Modern browsers में Intl.DateTimeFormat API display side को बिना किसी library के handle कर देता है।Intl.DateTimeFormatAPI in modern browsers handles the display side without any library.
क्या मुझे एक mobile app की जरूरत है?
MVP के लिए नहीं। एक अच्छी तरह बना progressive web app जिसमें push notifications हों (Web Push API के द्वारा) bidders को mobile पर जो कुछ भी चाहिए उसका 90% cover कर देता है। Native apps बाद में आते हैं, अगर business इसे justify करता है। जब वह दिन आए तो मैं Expo और React Native use करूँगा — iOS और Android दोनों में shared codebase, और टीम पहले से React को जानती है।ExpoandReact Nativewhen that day arrives — shared codebase across iOS and Android, and the team already knows React.
---
Online auctions चलाना एक legitimate engineering challenge है जो एक deceptively simple UI में लिपटी हुई है। Bidding interface तीन buttons और एक number है। इसके नीचे सब कुछ — consistency, fairness, real-time state, fraud prevention — यहीं actual work रहती है। Stack को शुरुआत से ही सही चुन लो और बाकी सब कुछ सिर्फ features हैं। अगर गलत चुन लो तो तुम वह व्यक्ति हो जो seller को समझा रहे हो कि उनका lot £12 में क्यों बिक गया।
Boring infrastructure build करो। Interesting products उसके ऊपर build करो।