जे लोक ड्रॉपशिपिंग स्टोअर सुरू करतात, त्यातील बहुतेक लोक शॉर्टकट शोधत असतात. ते फायदेशीर उत्पादने शोधण्यासाठी फोरम्स तपासतात, स्वस्त व्हर्च्युअल असिस्टंट्स कामावर ठेवतात आणि अल्गोरिदममुळे रातोरात श्रीमंत होण्याची आशा धरतात. मला हे कधीच आकर्षित करू शकले नाही. मी ड्रॉपशिपिंगकडे एक इंजिनिअरिंग समस्या म्हणून पाहिले. मी झटपट पैशांच्या मागे नव्हतो. मला इन्व्हेंटरी सिंकिंग (inventory syncing) सोडवायचे होते, बाजारपेठेतील बदलांनुसार प्रतिसाद देणारे प्राइसिंग अल्गोरिदम (pricing algorithms) तयार करायचे होते आणि माझे मानसिक संतुलन न गमावता सप्लायर APIs सोबत काम करायचे होते. Node.js आणि PostgreSQL वापरून मी तयार केलेल्या सिस्टमचा स्टोअर हा केवळ एक उप-परिणाम (side effect) होता.
स्टोअरकडे बॅकएंड सर्व्हिसप्रमाणे (Backend Service) वागा
ज्या क्षणी तुम्ही ड्रॉपशिपिंगकडे मार्केटिंगचा व्यवसाय म्हणून पाहणे थांबवता आणि त्याला 'डिस्ट्रिब्युटेड सिस्टम्स' (distributed systems) मधील एक आव्हान म्हणून पाहू लागता, तेव्हा समस्या मनोरंजक होऊ लागतात. जेव्हा तीन वेगवेगळे सप्लायर्स तुमच्या स्टॉकवर नियंत्रण ठेवतात, तेव्हा तुम्ही स्टोअरफ्रंट अचूक कसे ठेवू शकता? जेव्हा तेच सप्लायर्स तुम्हाला न सांगता किमती बदलतात, तेव्हा तुम्ही स्पर्धात्मक किंमत कशी ठरवाल? स्प्रेडशीट्समध्ये (spreadsheets) अडकून न पडता, ५० SKUs पासून ५,००० पर्यंत वाढणाऱ्या कॅटलॉगचे व्यवस्थापन तुम्ही कसे कराल?
या प्रश्नांची उत्तरे देण्यासाठी मी एक पाइपलाइन (pipeline) तयार केली. Node.js ने इव्हेंट-ड्रिव्हन आर्किटेक्चर (event-driven architecture) हाताळले, कारण एकाच वेळी अनेक सप्लायर कनेक्शन्स हाताळण्यासाठी मला नॉन-ब्लॉकिंग I/O ची गरज होती. PostgreSQL ने डेटाचा मुख्य आणि अचूक स्रोत (source of truth) म्हणून काम केले. मला स्कीमा डिझाइनबद्दल (schema design) खूप काळजी होती, कारण इन्व्हेंटरी टेबलमध्ये झालेली छोटीशी चूक पहिल्यांदाच एखादी वस्तू स्टॉक नसताना विकली गेली, तर ती nightmare (दुस्वप्न) ठरू शकते.
पाइपलाइन तयार करणे
मुख्य काम सांगायला सोपे होते: सप्लायर APIs मधून उत्पादनाचा डेटा मिळवणे. प्रत्यक्षात, याचा अर्थ असा होता की एकमेकांशी संवाद साधण्यासाठी बनवलेले नसलेले एंडपॉइंट्स (endpoints) मधून SKUs, वर्णने (descriptions), प्रतिमा, स्टॉक लेव्हल्स आणि किमती मिळवणे. मी Node.js मध्ये पोलिंग सर्व्हिसेस (polling services) लिहिल्या, ज्या ठराविक अंतराने सप्लायर फीड्सना रिक्वेस्ट पाठवत असत. प्रत्येक येणारा डेटा (payload) आमच्या अंतर्गत स्टोअरफ्रंट डेटाबेसमध्ये जाण्यापूर्वी व्हॅलिडेशन (validation) आणि मॅपिंग लेयर्समधून (mapping layers) जात असे.
मी उत्पादने, व्हेरिएंट्स, प्राइसिंग हिस्ट्री आणि सिंक लॉग्ससाठी स्वतंत्र टेबल्स वापरून PostgreSQL ची रचना केली. जेव्हा एखाद्या सप्लायरने गुपचूप फील्डचे नाव बदलले किंवा जिथे नंबर असायला हवा तिथे 'null' पाठवले, तेव्हा पाइपलाइनने ते पकडले आणि स्टोअरफ्रंटचा डेटा खराब करण्याऐवजी 'failure record' लिहिला. मी लॉग रो (log row) पाहून नेमका कोणता एंडपॉइंट बिघडला, तो किती वाजता घडला आणि कोणते फील्ड्स चुकीचे होते, हे अचूकपणे जाणून घेऊ शकत होतो. जेव्हा एखाद्या सप्लायरने वीकेंडला त्यांच्या API मध्ये "अपग्रेड" करण्याचा निर्णय घेतला, तेव्हा या ऑब्झर्व्हेबिलिटीमुळे (observability) मी अनेकदा वाचलो.
काय चांगले काम केले
ऑटोमेशनमुळे (Automation) प्रचंड वेळ वाचला. सुरुवातीला, मी मॅन्युअल पद्धत वापरून पाहिली: सप्लायरच्या स्प्रेडशीट्स डाउनलोड करणे, त्या हाताने स्वच्छ करणे, प्रतिमा फॉरमॅट करणे आणि स्टोअरवर CSVs अपलोड करणे. एकदा का कॅटलॉगमध्ये काही डझन पेक्षा जास्त वस्तू आल्या की ते अशक्य झाले. ऑटोमेटेड पाइपलाइनने नवीन लिस्टिंग, किमतीतील बदल आणि स्टॉक ॲडजस्टमेंट मी पुन्हा स्प्रेडशीटला स्पर्श न करताच हाताळले.
प्रॉडक्ट डिस्क्रिप्शन स्केल करण्यासाठी मी टेम्पलेट्सचा (templates) वापर केला. पाचशे जवळजवळ सारख्याच वस्तूंचे वेगळे वर्णन लिहिणे शाश्वत नव्हते. त्याऐवजी, मी एक टेम्पलेटिंग लेयर (templating layer) तयार केला जो सप्लायरचे गुणधर्म जसे की मटेरियल, डायमेन्शन्स किंवा रंग घेऊन त्यांना स्ट्रक्चर्ड डिस्क्रिप्शन ब्लॉक्समध्ये समाविष्ट करत असे. याचे आउटपुट इतके स्वच्छ होते की ते रूपांतरित करण्यासाठी सोपे होते आणि इतके सुसंगत होते की हजारो नवीन SKUs जोडण्यासाठी कोणत्याही मॅन्युअल कॉपीरायटिंगची गरज भासली नाही.
प्राईस मॉनिटरिंगने (Price monitoring) देखील माझ्या अपेक्षेपेक्षा जास्त चांगले काम केले. मी एक हलके मॉनिटरिंग लेयर तयार केले जे काही महत्त्वाच्या उत्पादनांच्या किमतींवर प्रतिस्पर्ध्यांच्या किमतींचा मागोवा घेत असे. जेव्हा किमतीत बदल आढळला, तेव्हा सिस्टमने मी सेट केलेल्या मर्यादांच्या (guardrails) आत आमच्या मार्जिनमध्ये आपोआप बदल केला. जर एखाद्या सप्लायरने होलसेल किंमत कमी केली, तर लिस्टिंगची किंमत काही दिवसांऐवजी काही मिनिटांतच बदलू शकत होती. त्या प्रतिसादात्मकतेमुळे (responsiveness) कमी मार्जिन असलेल्या वस्तूंमध्ये लक्षणीय फरक पडला.
काय बिघडले आणि का
सप्लायर APIs मध्ये सुसंगततेचा अभाव असतो. ही तक्रार नाही; हे एक वास्तव आहे. एक पार्टनर चांगल्या प्रकारे JSON आणि प्रेडिक्टेबल पेजिनेशन (predictable pagination) देतो. दुसरा सोमवारला camelCase टॅग्ससह XML देतो आणि बुधवारी snake_case देतो. रेट लिमिट्स (Rate limits) खूप उदार किंवा खूप कडक असू शकतात. डाउनटाइमची माहिती योग्य स्टेटस कोड्सऐवजी HTML एरर पेजेसद्वारे दिली जाते. शेवटी तुम्हाला अशा एंडपॉइंट्ससाठी डिफेन्सिव्ह पार्सर्स (defensive parsers) आणि रिट्राय लॉजिक (retry logic) लिहावे लागते, जे असे वागतात की जणू ते २००३ मध्ये डिझाइन केले होते.
इन्व्हेंटरी सिंकमध्ये अशा 'रेस कंडिशन्स' (race conditions) होत्या ज्याचा परिणाम माझ्या झोपेवर झाला. कल्पना करा: दोन ग्राहक काही सेकंदांच्या अंतराने शेवटचा एकच युनिट ऑर्डर करतात, किंवा एखादा खरेदीदार 'चेकआउट' (checkout) वर क्लिक करत असतानाच सप्लायरचा 'वेबहुक' (webhook) सांगतो की स्टॉक शून्य झाला आहे. माझे सुरुवातीचे 'रीड-देन-अपडेट' (read-then-update) लॉजिक पूर्णपणे निकामी ठरले. मला हाय-व्हेलॉसिटी (high-velocity) SKUs साठी 'ॲटॉमिक PostgreSQL ट्रान्झॅक्शन्स' (atomic PostgreSQL transactions) आणि 'पेसिमिस्टिक लॉकिंग' (pessimistic locking) वापरून सिंक लेयर पुन्हा लिहावा लागला. हे 'कॉन्करन्सी' (concurrency) मधील एक वेदनादायक आणि व्यावहारिक धडा होता, ज्यासाठी कोणताही ट्युटोरियल तुम्हाला तयार करू शकत नाही, विशेषतः जेव्हा पैशांचा प्रत्यक्ष प्रश्न समोर असतो.
माझी सर्वात मोठी चूक म्हणजे कस्टमर सपोर्ट ऑटोमेशनकडे (customer support automation) दुर्लक्ष करणे ही होती. मी डेटा पाइपलाईन्सवर (data pipelines) जास्त लक्ष केंद्रित केले आणि मानवी परिणामांकडे (human aftermath) दुर्लक्ष केले. ऑर्डर्स उशिरा आल्या. सप्लायर्सनी चुकीचा रंग पाठवला. मी जेव्हा API टाइमआउट्स (API timeouts) डीबग करत होतो, तेव्हा ग्राहकांनी पाठवलेले ईमेल्स तासनतास माझ्या इनबॉक्समध्ये पडून राहिले. माझ्याकडे कोणतेही 'तिकीट राउटिंग' (ticket routing), 'ऑटोमेटेड रिस्पॉन्स' (automated responses) किंवा 'चॅटबॉट हँडऑफ्स' (chatbot handoffs) नव्हते. तांत्रिक पायाभूत सुविधा (technical infrastructure) भक्कम होत्या. परंतु मानवी पायाभूत सुविधांचा (human infrastructure) अभाव होता, आणि त्या त्रुटीमुळे व्यवसायाचे नुकसान एखाद्या अस्थिर वेबहुकपेक्षा (flaky webhook) जास्त झाले.
एका इंजिनिअरप्रमाणे इमेजेस टेस्ट करणे
मी प्रॉडक्ट इमेजेसवर एक छोटा प्रयोग केला. मी 'सेशन-बेस्ड बकेटिंग' (session-based bucketing) शी संबंधित साध्या 'URL पॅरामीटर राउटिंग' (URL parameter routing) चा वापर करून वेगवेगळ्या वापरकर्त्यांना वेगवेगळ्या 'हिरो इमेजेस' (hero images) दाखवल्या. एका व्हेरिएंटमध्ये उत्पादन साध्या पांढऱ्या बॅकग्राउंडवर दाखवले होते. दुसऱ्या व्हेरिएंटमध्ये ते प्रत्यक्ष डेस्कवर एका 'लाइफस्टाईल सेटिंग'मध्ये (lifestyle setting) दाखवले होते. मी थेट ऑर्डर फ्लोशी (order flow) जोडलेल्या बेसिक 'इव्हेंट लॉगिंग' (event logging) चा वापर करून प्रत्येक बकेटसाठी 'कन्व्हर्जन रेट्स' (conversion rates) ट्रॅक केले.
छोट्या बदलांमुळे एंगेजमेंटमध्ये (engagement) सुधारणा झाली. 'लाइफस्टाईल शॉट्स' नेहमीच यशस्वी झाले नाहीत, पण जेव्हा ते यशस्वी झाले, तेव्हा झालेली वाढ इतकी लक्षणीय होती की त्यामुळे मी माझ्या प्राधान्यक्रमात बदल केला.