డ్రాప్షిప్పింగ్ స్టోర్ను ప్రారంభించే చాలా మంది షార్ట్కట్ల కోసం వెతుకుతుంటారు. వారు విన్నింగ్ ప్రొడక్ట్స్ కోసం ఫోరమ్లను వెతుకుతారు, తక్కువ ఖర్చుతో కూడిన వర్చువల్ అసిస్టెంట్లను నియమించుకుంటారు మరియు అల్గారిథమ్ ద్వారా రాత్రికి రాత్రే ధనవంతులవుతారని ఆశిస్తారు. అది నాకు ఎప్పుడూ నచ్చలేదు. నేను డ్రాప్షిప్పింగ్ను ఒక ఇంజనీరింగ్ సమస్యగా చూశాను. నేను త్వరగా డబ్బు సంపాదించడం కోసం వెతకలేదు. నేను ఇన్వెంటరీ సింకింగ్ సమస్యలను పరిష్కరించాలని, మార్కెట్ మార్పులకు అనుగుణంగా స్పందించే ప్రైసింగ్ అల్గారిథమ్లను నిర్మించాలని మరియు నా మానసిక ప్రశాంతతను కోల్పోకుండా సప్లయర్ APIలతో పోరాడాలని అనుకున్నాను. Node.js మరియు PostgreSQL ఉపయోగించి నేను నిర్మించిన సిస్టమ్ యొక్క ఒక ఉప ఉత్పత్తిగా (side effect) ఆ స్టోర్ తయారైంది.
స్టోర్ను ఒక బ్యాకెండ్ సర్వీస్లా పరిగణించండి
మీరు డ్రాప్షిప్పింగ్ను కేవలం ఒక మార్కెటింగ్ ప్రయత్నంగా చూడటం మానేసి, దానిని ఒక డిస్ట్రిబ్యూటెడ్ సిస్టమ్స్ సవాలుగా పరిగణించడం ప్రారంభించిన క్షణమే, సమస్యలు ఆసక్తికరంగా మారుతాయి. ముగ్గురు వేర్వేరు సప్లయర్లు మీ స్టాక్ను నియంత్రించినప్పుడు, స్టోర్ఫ్రంట్ను ఖచ్చితంగా ఎలా ఉంచాలి? అదే సప్లయర్లు మీకు చెప్పకుండా ధరలను మార్చినప్పుడు, మీరు పోటీతత్వంతో కూడిన ధరలను ఎలా నిర్ణయించాలి? స్ప్రెడ్షీట్లలో మునిగిపోకుండా, యాభై SKUల నుండి ఐదు వేల SKUల వరకు పెరిగే క్యాటలాగ్ను ఎలా నిర్వహించాలి?
ఈ ప్రశ్నలకు సమాధానం కోసం నేను ఒక పైప్లైన్ను నిర్మించాను. ఒకేసారి బహుళ సప్లయర్ కనెక్షన్లను నిర్వహించడానికి నాకు non-blocking I/O అవసరమైనందున, Node.js ఈ event-driven architectureను నిర్వహించింది. PostgreSQL ఒక ఖచ్చితమైన source of truthగా పనిచేసింది. నేను స్కీమా డిజైన్ గురించి చాలా జాగ్రత్తగా ఉన్నాను, ఎందుకంటే ఒక అస్తవ్యస్తమైన ఇన్వెంటరీ టేబుల్ వల్ల, లేని వస్తువును మీరు అమ్మేసినప్పుడు (oversell) అది ఒక పీడకలలా మారుతుంది.
పైప్లైన్ నిర్మాణం
ప్రధాన పని చెప్పడానికి సులభం: సప్లయర్ APIల నుండి ప్రొడక్ట్ డేటాను సేకరించడం. వాస్తవానికి, ఒకదానితో ఒకటి మాట్లాడుకోవడానికి రూపొందించబడని ఎండ్పాయింట్ల నుండి SKUలు, వివరణలు, చిత్రాలు, స్టాక్ స్థాయిలు మరియు ధరలను సేకరించడం అని అర్థం. సప్లయర్ ఫీడ్లను క్రమ పద్ధతిలో (staggered intervals) తనిఖీ చేసే polling servicesలను నేను Node.jsలో వ్రాశాను. ప్రతి ఇన్కమింగ్ పేలోడ్ మా అంతర్గత స్టోర్ఫ్రంట్ డేటాబేస్కు చేరకముందే validation మరియు mapping లేయర్ల ద్వారా వెళ్ళింది.
నేను PostgreSQLని ప్రొడక్ట్స్, వేరియంట్స్, ప్రైసింగ్ హిస్టరీ మరియు సింక్ లాగ్ల కోసం విడివిడి టేబుల్స్తో రూపొందించాను. ఒక సప్లయర్ నిశ్శబ్దంగా ఫీల్డ్ పేరును మార్చినప్పుడు లేదా నంబర్ ఉండాల్సిన చోట null పంపినప్పుడు, పైప్లైన్ దానిని గుర్తించి, స్టోర్ఫ్రంట్ను దెబ్బతీయకుండా ఒక ఫెయిల్యూర్ రికార్డ్ను రాసింది. నేను ఒక లాగ్ రో (log row) చూసి, ఏ ఎండ్పాయింట్ విఫలమైంది, అది ఏ సమయంలో జరిగింది మరియు ఏ ఫీల్డ్లు తప్పుగా ఉన్నాయో ఖచ్చితంగా తెలుసుకోగలిగేవాడిని. ఒక సప్లయర్ వీకెండ్లో వారి APIని "అప్గ్రేడ్" చేయాలని నిర్ణయించుకున్నప్పుడు, ఆ observability నన్ను ఒకటి కంటే ఎక్కువసార్లు కాపాడింది.
ఏవి బాగా పనిచేశాయి
ఆటోమేషన్ వల్ల చాలా సమయం ఆదా అయ్యింది. ప్రారంభంలో, నేను మాన్యువల్ పద్ధతిని ప్రయత్నించాను: సప్లయర్ స్ప్రెడ్షీట్లను డౌన్లోడ్ చేయడం, వాటిని చేత్తో క్లీన్ చేయడం, చిత్రాలను ఫార్మాట్ చేయడం మరియు స్టోర్కు CSVలను అప్లోడ్ చేయడం. క్యాటలాగ్ కొన్ని డజన్ల వస్తువులను దాటిన తర్వాత అది అసాధ్యంగా మారింది. ఆటోమేటెడ్ పైప్లైన్ కొత్త లిస్టింగ్స్, ధరల అప్డేట్లు మరియు స్టాక్ సర్దుబాట్లను నేను మళ్ళీ స్ప్రెడ్షీట్ను తాకాల్సిన అవసరం లేకుండానే నిర్వహించింది.
టెంప్లేట్ల ద్వారా ప్రొడక్ట్ వివరణలను స్కేల్ చేయడం సాధ్యమైంది. దాదాపు ఒకేలా ఉండే ఐదు వందల వస్తువుల కోసం విభిన్నమైన వివరణలు రాయడం సాధ్యం కాదు. దానికి బదులుగా, మెటీరియల్, డైమెన్షన్స్ లేదా కలర్ వంటి సప్లయర్ ఆట్రిబ్యూట్లను తీసుకుని, వాటిని స్ట్రక్చర్డ్ డిస్క్రిప్షన్ బ్లాక్లలో చేర్చే ఒక టెంప్లేటింగ్ లేయర్ను నేను నిర్మించాను. దీని ద్వారా వచ్చిన అవుట్పుట్ చాలా స్పష్టంగా మరియు స్థిరంగా ఉండేది, దీనివల్ల వెయ్యి కొత్త SKUలను జోడించడానికి ఎటువంటి మాన్యువల్ కాపీరైటింగ్ అవసరం లేదు.
ధరల పర్యవేక్షణ (Price monitoring) కూడా నా అంచనాలను మించిపోయింది. కొన్ని ముఖ్యమైన ఉత్పత్తుల ధరలను ట్రాక్ చేసే ఒక లైట్వెయిట్ మానిటరింగ్ లేయర్ను నేను నిర్మించాను. ధరలలో మార్పులను గుర్తించినప్పుడు, నేను కాన్ఫిగర్ చేసిన గైడ్రైల్స్ (guardrails) లోపల సిస్టమ్ మా మార్జిన్లను స్వయంచాలకంగా సర్దుబాటు చేసింది. ఒక సప్లయర్ హోల్సేల్ ధరను తగ్గించినట్లయితే, ఆ మార్పు రోజుల్లో కాకుండా నిమిషాల్లోనే లిస్టింగ్ ధరలో ప్రతిబింబించేలా చేయవచ్చు. ఆ స్పందన (responsiveness) తక్కువ మార్జిన్ ఉన్న వస్తువుల విషయంలో గణనీయమైన తేడాను చూపింది.
ఏవి విఫలమయ్యాయి మరియు ఎందుకు
సప్లయర్ APIలలో స్థిరత్వం (consistency) ఉండదు. ఇది ఫిర్యాదు కాదు; ఇది ఒక అనివార్యమైన వాస్తవం. ఒక భాగస్వామి ఊహించదగిన పేజినేషన్తో క్లీన్ JSONను అందిస్తారు. మరొకరు సోమవారం camelCase ట్యాగ్లతో, బుధవారం snake_caseతో XMLను అందిస్తారు. రేట్ లిమిట్లు చాలా తక్కువ నుండి చాలా ఎక్కువగా మారుతుంటాయి. డౌన్టైమ్ గురించి సరైన స్టేటస్ కోడ్ల ద్వారా కాకుండా HTML ఎర్రర్ పేజీల ద్వారా తెలియజేస్తారు. 2003లో రూపొందించినట్లుగా ప్రవర్తించే ఎండ్పాయింట్ల కోసం మీరు డిఫెన్సివ్ పార్సర్లు మరియు రీట్రై లాజిక్ను రాయాల్సి వస్తుంది.
ఇన్వెంటరీ సింక్లో రేస్ కండిషన్స్ (race conditions) వల్ల నాకు నిద్రలేని రాత్రులు గడిచాయి. ఒకసారి ఊహించండి: ఇద్దరు కస్టమర్లు సెకన్ల వ్యవధిలో చివరి యూనిట్ను ఆర్డర్ చేస్తారు, లేదా ఒక కొనుగోలుదారు చెక్అవుట్ క్లిక్ చేసిన సరిగ్గా అదే సమయంలో సప్లయర్ వెబ్హుక్ (supplier webhook) స్టాక్ సున్నా అయిందని మీకు చెబుతుంది. నా ప్రారంభ 'read-then-update' లాజిక్ ఘోరంగా విఫలమైంది. హై-వెలాసిటీ SKUల కోసం అటామిక్ PostgreSQL ట్రాన్సాక్షన్స్ (atomic PostgreSQL transactions) మరియు పెసిమిస్టిక్ లాకింగ్ (pessimistic locking) ఉపయోగించి నేను సింక్ లేయర్ను తిరిగి రాయాల్సి వచ్చింది. నిజమైన డబ్బు పణంగా ఉన్నప్పుడు ఎదురయ్యే కన్కరెన్సీ (concurrency) సమస్యల గురించి ఏ ట్యుటోరియల్ కూడా మీకు నేర్పించలేని ఒక బాధాకరమైన, ఆచరణాత్మక పాఠం ఇది.
కస్టమర్ సపోర్ట్ ఆటోమేషన్ను విస్మరించడమే నా అతిపెద్ద వైఫల్యం. నేను డేటా పైప్లైన్ల (data pipelines) పైనే అతిగా దృష్టి పెట్టాను మరియు దాని వల్ల కలిగే మానవ సంబంధిత పరిణామాలను ఒక అదనపు అంశంగా భావించాను. ఆర్డర్లు ఆలస్యంగా వచ్చాయి. సప్లయర్లు తప్పు రంగును పంపారు. నేను API టైమ్-అవుట్లను (API timeouts) డీబగ్ చేస్తున్న సమయంలో కస్టమర్లు పంపిన ఈమెయిల్స్ గంటల తరబడి నా ఇన్బాక్స్లోనే ఉండిపోయాయి. నా దగ్గర టికెట్ రూటింగ్ (ticket routing), ఆటోమేటెడ్ రెస్పాన్సెస్ (automated responses), లేదా చాట్బాట్ హ్యాండ్ఆఫ్స్ (chatbot handoffs) ఏవీ లేవు. సాంకేతిక మౌలిక సదుపాయాలు (technical infrastructure) బలంగా ఉన్నాయి. కానీ మానవ మౌలిక సదుపాయాలు (human infrastructure) లేవు, మరియు ఆ లోటు ఒక అస్థిరమైన వెబ్హుక్ (flaky webhook) కంటే వ్యాపారానికి ఎక్కువ నష్టం కలిగించింది.
ఒక ఇంజనీర్లా చిత్రాలను పరీక్షించడం
నేను ప్రొడక్ట్ చిత్రాలపై ఒక సైడ్ ప్రయోగం నిర్వహించాను. సెషన్-ఆధారిత బకెటింగ్ (session-based bucketing) తో అనుసంధానించబడిన సాధారణ URL పారామీటర్ రూటింగ్ ఉపయోగించి, నేను వేర్వేరు వినియోగదారులకు వేర్వేరు హీరో చిత్రాలను (hero images) చూపించాను. ఒక వెర్షన్లో ఉత్పత్తిని సాధారణ తెల్లటి బ్యాక్గ్రౌండ్లో చూపించాను. మరొక వెర్షన్లో దానిని ఒక డెస్క్పై లైఫ్ స్టైల్ సెట్టింగ్లో చూపించాను. ఆర్డర్ ఫ్లోతో నేరుగా అనుసంధానించబడిన బేసిక్ ఈవెంట్ లాగింగ్ (event logging) ఉపయోగించి ప్రతి బకెట్ యొక్క కన్వర్షన్ రేట్లను (conversion rates) నేను ట్రాక్ చేశాను.
చిన్న మార్పులు ఎంగేజ్మెంట్ను మెరుగుపరిచాయి. లైఫ్ స్టైల్ షాట్లు ఎప్పుడూ గెలవలేదు, కానీ అవి గెలిచినప్పుడు, నా ప్రాధాన్యతలను మార్చుకునేంత గణనీయమైన మెరుగుదల కనిపించింది.