2021 में, एक क्लाइंट मेरे पास एक सीधा-सादा ब्रीफ लेकर आया था: "हमें एक नीलामी साइट चाहिए। eBay जैसी, लेकिन निश, -- क्लासिक मोटरसाइकिल पार्ट्स।" तीन महीने, दो छोड़े गए प्रोटोटाइप, और एक सचमुच शर्मनाक प्रोडक्शन आउटेज के बाद, मेरे पास विचार थे। मजबूत विचार। हम आखिर में वहाँ पहुँचे, लेकिन मैं इसे अब इसी तरीके से नहीं बनाता। बिल्कुल नहीं।
मुख्य बात: 2026 के लिए एक नीलामी प्लेटफॉर्म Next.js, Supabase के साथ रीयल-टाइम चैनलों के लिए लाइव बिडिंग के साथ, और Stripe है; मुश्किल हिस्सा स्टैक नहीं है, बल्कि समवर्ती परिस्थितियों में बिड स्टेट की सत्यता बनाए रखना है।A 2026 auction platform is Next.js, Supabase with realtime channels for live bidding, and Stripe; the hard part is bid-state integrity under concurrency, not the stack.
नीलामी प्लेटफॉर्म धोखे से मुश्किल होते हैं। सतह पर यह सिर्फ लिस्टिंग, बिड, और एक टाइमर है। लेकिन जैसे ही दो यूजर्स मिलीसेकंड के भीतर बिड करते हैं, या आपका WebSocket कनेक्शन ठीक तब ड्रॉप हो जाता है जब काउंटडाउन जीरो को हिट करता है, या आपका पेमेंट प्रोसेसर कैप्चर के बीच में टाइम आउट हो जाता है -- अचानक आप एक बहुत ही गुस्से वाले विक्रेता को समझा रहे हैं कि उनका 1967 BSA Lightning £12 के लिए क्यों बिक गया। तो मुझे आपको बताएं कि मैं 2026 में वास्तव में क्या बनाता, टूल दर टूल, फैसला दर फैसला।
---
मुख्य आर्किटेक्चर फैसला: मोनोलिथ या सर्विसेज़?
किसी को पहले वर्जन के लिए माइक्रोसर्विसेज़ पर बेचने दें मत। मुझे मतलब है।
मैंने यह गलती बार-बार देखी है -- फाउंडर एक सलाहकार को नियुक्त करता है, सलाहकार व्हाइटबोर्ड पर आठ अलग सर्विसेज को डायग्राम करता है, सभी सिर हिलाते हैं, और छह महीने बाद कुछ भी शिप नहीं होता क्योंकि टीम एक प्लेटफॉर्म पर इंटर-सर्विस लेटेंसी को डीबग कर रहा है जिसके 40 यूजर्स हैं। एक नीलामी MVP या यहाँ तक कि एक मध्यम रूप से स्केल किए गए प्रोडक्ट के लिए (कहते हैं, 50,000 मासिक सक्रिय यूजर्स से कम), एक मॉड्यूलर मोनोलिथ सही कॉल है।modular monolith is the right call.
मैं क्या चुनता: फ्रंटएंड और API लेयर पर Next.js, एक Node.js बैकएंड के साथ। सिर्फ इसलिए नहीं कि यह ट्रेंडी है। क्योंकि Next.js 14+ में सर्वर कंपोनेंट्स मॉडल वास्तव में नीलामी लिस्टिंग पेजेस की जटिलता को कम करता है जहाँ SEO वास्तव में महत्वपूर्ण है -- आप चाहते हैं कि वह लॉट डिस्क्रिप्शन्स इंडेक्स हो जाएँ। API रूट्स हल्का-फुल्का काम करते हैं; भारी रीयल-टाइम सामान कहीं और रहती है (एक पल में इसके बारे में और)।Next.js on 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 किसी भी लेनदेन-आधारित चीज के लिए। नीलामियाँ गहरे संबंधपूर्ण हैं -- यूजर्स, लॉट्स, बिड्स, रिजर्व्स, इनवॉयस -- और आप चाहते हैं कि फॉरेन की कंस्ट्रेंट्स असली काम कर रहे हों, न कि विब्स-आधारित एप्लीकेशन लॉजिक। मैं 2026 में इसे Supabase पर चलाता क्योंकि आपको Postgres, रो-लेवल सिक्यूरिटी, और एक रीयल-टाइम सबस्क्रिप्शन लेयर बेक्ड इन मिलती है, जो तीन अलग इंफ्रास्ट्रक्चर चिंताओं को एक बिल में बदल देती है।Supabase in 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: वह हिस्सा जो आपको तोड़ देगा
यह वह जगह है जहाँ अधिकांश नीलामी प्लेटफॉर्म मर जाते हैं। या कम से कम लँगड़े हो जाते हैं।
मौलिक समस्या: बिडिंग को तत्काल लगना चाहिए, सुसंगत होना चाहिए, और रेस कंडीशन्स को सही तरीके से हैंडल करना चाहिए। अगर दो यूजर्स एक ही मिलीसेकंड में एक बिड सबमिट करते हैं, तो उनमें से एक जीतता है। डेटाबेस तय करता है कि कौन जीता। फ्रंटएंड नहीं, लोड बैलेंसर नहीं -- डेटाबेस, एक सही तरीके से लिखे गए ट्रांजेक्शन के माध्यम से SELECT FOR UPDATE के साथ।SELECT FOR UPDATE.
रीयल-टाइम लेयर के लिए, मैं 2026 में Ably का उपयोग करता हूँ कच्चे WebSockets को रोल करने के बजाय। मैंने Seahawk में 2022 पर एक प्रॉपर्टी नीलामी प्रोजेक्ट पर कच्चा दृष्टिकोण आजमाया था -- सेल्फ-होस्टेड socket.io, Redis pub/sub, सब कुछ। यह ठीक था जब तक कि यह नहीं था। Ably आपको गारंटीकृत संदेश क्रम, कनेक्शन स्टेट रिकवरी देता है (इसलिए अगर एक बोली लगाने वाले का फोन नीलामी के बीच WiFi से 4G पर स्विच करता है, तो वे जीतने वाली बिड को चुप्पी से मिस नहीं करते), और एक समझदारी भरा डैशबोर्ड। स्केल पर प्राइसिंग असली है, लेकिन अधिकांश नीलामी ऑपरेटर्स के लिए यह इंफ्रास्ट्रक्चर जटिलता की तुलना में शोर है।Ably in 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" समस्या को संभालना
नीलामी स्निपिंग -- आखिरी कुछ सेकंड में एक बिड लगाना -- आपके क्लाइंट के आधार पर या तो एक विशेषता या एक बग है। eBay प्रसिद्ध रूप से इसे अनुमति देता है। कई विशेषज्ञ नीलामी घर अगर एक बिड अंतिम मिनट में आती है तो टाइमर को 30-60 सेकंड से बढ़ाते हैं। इसे "सॉफ्ट क्लोज" या "एंटी-स्निपिंग" लॉजिक कहा जाता है। इसे दिन एक से बनाएँ। नियम सरल है:
- बोली N सेकंड से कम समय बचे आती है
- लेनदेन पुष्टि करता है कि बोली वैध और सर्वोच्च है
- नीलामी समाप्ति समय N सेकंड तक बढ़ता है
- नया समाप्ति समय Ably के माध्यम से सभी जुड़े हुए क्लाइंट्स को प्रसारित होता है
यह शायद 40 लाइनों का सर्वर लॉजिक है। इसे छोड़ना और बाद में लगाना एक सिरदर्दी है जिसे आप नहीं चाहते।
---
भुगतान: चतुर मत बनिए
मैंने नीलामी साइटों पर लोगों को विदेशी भुगतान सेटअप के लिए जाते हुए देखा है क्योंकि नीलामियों की अजीब ज़रूरतें होती हैं -- आप भुगतान विवरण पहले से कैप्चर करते हैं, केवल जब लॉट बंद हो तो चार्ज करते हैं, हो सकता है कि डिपॉजिट होल्ड करना पड़े, हो सकता है कि आउटबिड होने पर तुरंत रिफंड करना पड़े। सब सच है। सब Stripe से हल होता है बिना Stripe के डॉक्स छोड़े।
2026 में Stripe अभी भी auction operators के विशाल बहुमत के लिए सही जवाब है। विशेष रूप से: in 2026 is still the right answer for the vast majority of auction operators. Specifically:
- standard bid-to-charge flow के लिए Stripe Payment Intents for the standard bid-to-charge flow
capture_method: manual एक card को authorize करने के लिए बिना charge किए (deposit holds के लिए आवश्यक)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 अधिकांश 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 is 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 routes के लिए Vercel -- ज़ीरो कॉन्फ़िग डिप्लॉयमेंट्स, हर ब्रांच के लिए preview URLs, जहां ज़रूरत हो edge functions for the Next.js frontend and API routes -- zero config deployments, preview URLs per branch, edge functions where needed
- PostgreSQL और auth के लिए Supabase for PostgreSQL and auth
- WebSockets के लिए Ably for WebSockets
- खोज के लिए Typesense Cloud for search
- सब कुछ के सामने Cloudflare -- फ्री टियर DDoS, इमेज ऑप्टिमाइज़ेशन, और caching को बिना परेशानी के हैंडल करता है in front of everything -- free tier handles DDoS, image optimisation, and caching without fuss
- विक्रेता द्वारा अपलोड की गई लॉट इमेजों के लिए Uploadcare या Cloudinary (2026 में अपने सर्वर पर यूजर अपलोड कभी स्टोर न करें, कृपया) or Cloudinary for seller-uploaded lot images (never store user uploads on your own server in 2026, please)
उस स्टैक में कोई Kubernetes नहीं है, कोई self-managed Redis cluster नहीं है, कोई DevOps hire नहीं है। एक solo developer या छोटी टीम इसे चला सकती है। और महत्वपूर्ण बात -- यह बिना re-architect किए स्केल करता है। Vercel और Supabase को traffic spike हैंडल करेंगे जब आप किसी ट्रेड पब्लिकेशन में featured हों और 8,000 लोग एक घंटे में आपकी साइट को हिट करें।Vercel and Supabase will handle the traffic spike when you get featured in a trade publication and 8,000 people hit your site in an hour.
एक इन्फ्रास्ट्रक्चर गलती जो मैं बार-बार देखता हूँ
लोग बैकग्राउंड जॉब्स को भूल जाते हैं। नीलामी क्लोज़ इवेंट्स user-triggered नहीं होते -- वे एक specific timestamp पर होते हैं, server-side। आपको एक reliable job scheduler की ज़रूरत है। मैं इसके लिए 2026 में Inngest का इस्तेमाल करूंगा। यह time-based triggers हैंडल करता है, retries, और आपको एक event log देता है जो असल में उपयोगी है जब आप debug कर रहे हों "लॉट 447 क्यों winner email भेजे बिना बंद हो गया"। अपने सर्वर पर simple cron न लगाएं। जब आपका सर्वर restart हो, आपकी cron state चली जाती है।Inngest for 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 simple cron on your server. When your server restarts, your cron state is gone.
---
एडमिन और सेलर टूल्स
सेलर्स को लिस्टिंग बनानी होती है, इमेज अपलोड करनी होती हैं, रिजर्व प्राइसेस सेट करने होते हैं, और बिड हिस्ट्री देखनी होती है। बायर्स को विशलिस्ट्स, बिड अलर्ट्स, और इनवॉइस डाउनलोड चाहिए। ये ग्लैमरस फीचर्स नहीं हैं। ये वो हैं जिनके बारे में क्लाइंट्स आपको बुधवार रात 9 बजे फोन करते हैं।
admin panel के लिए, मैं Retool या budget पर निर्भर करते हुए custom Next.js dashboard के ऊपर हल्के से बनाऊंगा। Retool genuinely तेज़ है सेटअप के लिए और नीलामी admin tasks की 80% को हैंडल करता है -- listings को approve करना, users को manage करना, bids को void करना -- बिना ज़्यादा कोड लिखे। कुछ भी client-facing के लिए मैं Next.js में properly बनाऊंगा, क्योंकि Retool को iframe में embed करना एक अच्छा user experience नहीं है।Retool or 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.
ईमेल नोटिफिकेशन्स -- outbid alerts, lot closing soon, invoice ready -- 2026 में Resend के ज़रिए जाते हैं। इसने करीब 18 महीने पहले मेरे स्टैक में SendGrid को replace किया और मैंने पीछे मुड़कर नहीं देखा। developer experience notably बेहतर है और deliverability solid रहा है।Resend in 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.
---
नीलाम के लिए विशेष सुरक्षा विचार
नीलाम प्लेटफॉर्म्स बिड मैनिपुलेशन अटेम्प्ट्स को आकर्षित करते हैं। शिल बिडिंग (एक सेलर अपने लॉट की कीमत को नकली अकाउंट्स का इस्तेमाल करके बढ़ाता है), अकाउंट टेकओवर्स धोखाधड़ी वाली जीतने वाली बिड्स लगाने के लिए, और पेमेंट फ्रॉड सब कुछ रियल हैं और आम ई-कॉमर्स के मुकाबले बेतहाशा ज्यादा आम हैं।
कुछ चीजें हैं जो मैं शुरुआत से ही बेक कर दूंगा:
- bid submission पर rate limiting -- max N bids प्रति user प्रति मिनट प्रति लॉट, API layer पर enforce किया। 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 Pro is worth the cost if you're operating at any meaningful scale
ईमानदारी से कहूँ तो सबसे महत्वपूर्ण चीज़ लॉगिंग है। हर बिड प्रयास, हर विफल भुगतान, हर खाता कार्रवाई को लॉग करें। जब कुछ गलत होता है -- और होगा -- आप एक पूर्ण ऑडिट ट्रेल चाहते हैं। Supabase की अंतर्निहित लॉगिंग और Axiom पर एक हल्के सेटअप के साथ यह ज्यादा प्रयास के बिना हो जाता है।Axiom covers this without much effort.
---
FAQ
एक छोटी, स्थानीय नीलामी साइट के लिए न्यूनतम viable stack क्या है?
अगर आप एक स्थानीय नीलामी घर के लिए बना रहे हैं जहाँ शायद 200 उपयोगकर्ता हैं और साप्ताहिक बिक्री है, तो आपको Ably या Typesense की ज़रूरत नहीं है। Auctions for WooCommerce जैसी प्लगइन के साथ WordPress आपको आश्चर्यजनक रूप से दूर तक ले जाती है। मैंने इनमें से तीन क्षेत्रीय नीलामी घरों के लिए सेटअप किए हैं -- प्राचीन वस्तुएँ, कृषि उपकरण, उस तरह की चीज़ें। जिस क्षण आपको भार के अंतर्गत वास्तविक समय की प्रतिस्पर्धी बिडिंग की ज़रूरत होती है, तुरंत इससे आगे निकल जाते हैं।WordPress with a plugin like Auctions for WooCommerce gets 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 वास्तव में वास्तविक समय की बिड स्थिति के लिए एक उचित विकल्प है। मुझे 2026 में Supabase पसंद करने का कारण SQL है -- नीलामी डेटा के पास बहुत सारी संबंधात्मक संरचना है (लॉट बिक्री से संबंधित हैं, बिड लॉट और उपयोगकर्ताओं से संबंधित हैं, चालान बिड को संदर्भित करते हैं), और दस्तावेज़ डेटाबेस को इसके लिए क्वेरी करना गंदा हो जाता है। लेकिन अगर आपकी टीम पहले से ही Firebase को गहराई से जानती है, तो इसके लिए स्विच न करें।
मैं auction end times के लिए time zones को कैसे handle करूँ?
सब कुछ UTC में स्टोर करें। हमेशा। ब्राउज़र के माध्यम से उपयोगकर्ता के स्थानीय समय क्षेत्र में प्रदर्शित करें। यह स्पष्ट लगता है और मैं अभी भी इसे लगभग एक में पाँच परियोजनाओं में गलत तरीके से किए जाते देखता हूँ। आधुनिक ब्राउज़रों में Intl.DateTimeFormat API बिना किसी लाइब्रेरी के डिस्प्ले साइड को संभालता है।Intl.DateTimeFormat API in modern browsers handles the display side without any library.
क्या मुझे एक mobile app की जरूरत है?
MVP के लिए नहीं। पुश नोटिफिकेशन के साथ एक अच्छी तरह से निर्मित प्रगतिशील वेब ऐप (Web Push API के माध्यम से) बोलीदाताओं को मोबाइल पर वास्तव में 90% आवश्यकता को कवर करता है। नेटिव ऐप्स बाद में आते हैं, अगर व्यवसार इसकी गारंटी देता है। मैं उस दिन आने पर Expo और React Native का उपयोग करूँगा -- iOS और Android में साझा कोडबेस, और टीम पहले से ही React जानती है।Expo and React Native when that day arrives -- shared codebase across iOS and Android, and the team already knows React.
---
ऑनलाइन नीलामी चलाना एक वैध इंजीनियरिंग चुनौती है जो धोखे से सरल UI में तैयार है। बिडिंग इंटरफेस तीन बटन और एक संख्या है। इसके नीचे सब कुछ -- स्थिरता, निष्पक्षता, वास्तविक समय की स्थिति, धोखाधड़ी की रोकथाम -- वह जगह है जहाँ वास्तविक काम रहता है। शुरुआत से स्टैक सही तरीके से प्राप्त करें और बाकी सब कुछ बस सुविधाएँ हैं। इसे गलत तरीके से प्राप्त करें और आप वह व्यक्ति हैं जो विक्रेता को समझा रहे हैं कि उनका लॉट £12 में क्यों बेचा गया।
Boring infrastructure build करो। Interesting products उसके ऊपर build करो।