ಡ್ರಾಪ್ಶಿಪ್ಪಿಂಗ್ ಸ್ಟೋರ್ ತೆರೆಯುವ ಹೆಚ್ಚಿನ ಜನರು ಶಾರ್ಟ್ಕಟ್ಗಳಿಗಾಗಿ ಹುಡುಕಾಟ ನಡೆಸುತ್ತಾರೆ. ಅವರು ಗೆಲ್ಲುವ ಉತ್ಪನ್ನಗಳಿಗಾಗಿ ಫೋರಂಗಳಲ್ಲಿ ಹುಡುಕಾಡುತ್ತಾರೆ, ಅಗ್ಗದ ವರ್ಚುವಲ್ ಅಸಿಸ್ಟೆಂಟ್ಗಳನ್ನು ನೇಮಿಸಿಕೊಳ್ಳುತ್ತಾರೆ ಮತ್ತು ಅಲ್ಗಾರಿದಮ್ ರಾತ್ರೋರಾತ್ರಿ ಶ್ರೀಮಂತನನ್ನಾಗಿ ಮಾಡುತ್ತದೆ ಎಂದು ಭಾವಿಸುತ್ತಾರೆ. ಇದು ನನಗೆ ಎಂದಿಗೂ ಆಕರ್ಷಕವಾಗಿರಲಿಲ್ಲ. ನಾನು ಡ್ರಾಪ್ಶಿಪ್ಪಿಂಗ್ ಅನ್ನು ಒಂದು ಎಂಜಿನಿಯರಿಂಗ್ ಸಮಸ್ಯೆಯಾಗಿ ನೋಡಿದೆ. ನಾನು ಬೇಗ ಹಣ ಗಳಿಸುವ ಉದ್ದೇಶ ಹೊಂದಿರಲಿಲ್ಲ. ನಾನು ಇನ್ವೆಂಟರಿ ಸಿಂಕಿಂಗ್ (inventory syncing) ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು, ಮಾರುಕಟ್ಟೆಯ ಬದಲಾವಣೆಗಳಿಗೆ ತಕ್ಕಂತೆ ಪ್ರತಿಕ್ರಿಯಿಸುವ ಬೆಲೆ ನಿರ್ಧರಿಸುವ ಅಲ್ಗಾರಿದಮ್ಗಳನ್ನು ನಿರ್ಮಿಸಲು ಮತ್ತು ಸಪ್ಲೈಯರ್ API ಗಳೊಂದಿಗೆ ವ್ಯವಹರಿಸಲು ಬಯಸಿದೆ. Node.js ಮತ್ತು PostgreSQL ಬಳಸಿ ನಾನು ನಿರ್ಮಿಸಿದ ವ್ಯವಸ್ಥೆಯ ಒಂದು ಉಪ ಉತ್ಪನ್ನವಾಗಿ ಆ ಸ್ಟೋರ್ ಹೊರಹೊಮ್ಮಿತು.
ಸ್ಟೋರ್ ಅನ್ನು ಬ್ಯಾಕೆಂಡ್ ಸೇವೆಯಂತೆ (Backend Service) ಪರಿಗಣಿಸಿ
ನೀವು ಡ್ರಾಪ್ಶಿಪ್ಪಿಂಗ್ ಅನ್ನು ಕೇವಲ ಮಾರ್ಕೆಟಿಂಗ್ ತಂತ್ರ ಎಂದು ಯೋಚಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ, ಅದನ್ನು ಡಿಸ್ಟ್ರಿಬ್ಯೂಟೆಡ್ ಸಿಸ್ಟಮ್ಸ್ (distributed systems) ಸವಾಲಾಗಿ ನೋಡಲು ಪ್ರಾರಂಭಿಸಿದ ಕ್ಷಣವೇ, ಸಮಸ್ಯೆಗಳು ಆಸಕ್ತಿದಾಯಕವಾಗುತ್ತವೆ. ಮೂರು ವಿಭಿನ್ನ ಸಪ್ಲೈಯರ್ಗಳು ನಿಮ್ಮ ಸ್ಟಾಕ್ ಅನ್ನು ನಿಯಂತ್ರಿಸುತ್ತಿರುವಾಗ, ಸ್ಟೋರ್ಫ್ರಂಟ್ ಅನ್ನು ನಿಖರವಾಗಿರಿಸುವುದು ಹೇಗೆ? ಅದೇ ಸಪ್ಲೈಯರ್ಗಳು ನಿಮಗೆ ತಿಳಿಸದೆ ಬೆಲೆಯನ್ನು ಬದಲಾಯಿಸಿದಾಗ, ಸ್ಪರ್ಧಾತ್ಮಕ ಬೆಲೆಯನ್ನು ಹೇಗೆ ನಿಗದಿಪಡಿಸುವುದು? ಸ್ಪ್ರೆಡ್ಶೀಟ್ಗಳಲ್ಲಿ ಮುಳುಗದೆ, ಐವತ್ತು SKUಗಳಿಂದ ಐದು ಸಾವಿರ SKUಗಳವರೆಗೆ ಬೆಳೆಯುವ ಕ್ಯಾಟಲಾಗ್ ಅನ್ನು ನೀವು ಹೇಗೆ ನಿರ್ವಹಿಸುತ್ತೀರಿ?
ಈ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸಲು ನಾನು ಒಂದು ಪೈಪ್ಲೈನ್ ನಿರ್ಮಿಸಿದೆ. ಏಕಕಾಲದಲ್ಲಿ ಹಲವಾರು ಸಪ್ಲೈಯರ್ ಕನೆಕ್ಷನ್ಗಳನ್ನು ನಿರ್ವಹಿಸಲು ನನಗೆ non-blocking I/O ಅಗತ್ಯವಿದ್ದ ಕಾರಣ, Node.js ಇವೆಂಟ್-ಡ್ರಿವನ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ನಿರ್ವಹಿಸಿತು. PostgreSQL ನಿಖರವಾದ ಮೂಲ ಮಾಹಿತಿಯ ಮೂಲವಾಗಿ (source of truth) ಕಾರ್ಯನಿರ್ವಹಿಸಿತು. ನಾನು ಸ್ಕೀಮಾ ವಿನ್ಯಾಸದ (schema design) ಬಗ್ಗೆ ಹೆಚ್ಚಿನ ಕಾಳಜಿ ವಹಿಸಿದೆ, ಏಕೆಂದರೆ ಅಸ್ತವ್ಯಸ್ತವಾದ ಇನ್ವೆಂಟರಿ ಟೇಬಲ್, ಲಭ್ಯವಿಲ್ಲದ ವಸ್ತುವನ್ನು ನೀವು ಮಾರಾಟ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿದಾಗ ದೊಡ್ಡ ಸಮಸ್ಯೆಯಾಗುತ್ತದೆ.
ಪೈಪ್ಲೈನ್ ನಿರ್ಮಾಣ
ಮೂಲ ಕೆಲಸ ಸರಳವಾಗಿತ್ತು: ಸಪ್ಲೈಯರ್ APIಗಳಿಂದ ಉತ್ಪನ್ನದ ಡೇಟಾವನ್ನು ಪಡೆಯುವುದು. ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಇದರರ್ಥ ಪರಸ್ಪರ ಸಂವಹನ ನಡೆಸಲು ವಿನ್ಯಾಸಗೊಳಿಸದ ಎಂಡ್ಪಾಯಿಂಟ್ಗಳಿಂದ SKUಗಳು, ವಿವರಣೆಗಳು, ಚಿತ್ರಗಳು, ಸ್ಟಾಕ್ ಮಟ್ಟ ಮತ್ತು ಬೆಲೆಗಳನ್ನು ಪಡೆಯುವುದು ಎಂದರ್ಥ. ನಾನು Node.js ನಲ್ಲಿ ಪೋಲಿಂಗ್ ಸರ್ವಿಸ್ಗಳನ್ನು ಬರೆದೆವು, ಅವುಗಳು ವಿಭಿನ್ನ ಸಮಯದ ಅಂತರದಲ್ಲಿ ಸಪ್ಲೈಯರ್ ಫೀಡ್ಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತಿದ್ದವು. ಪ್ರತಿಯೊಂದು ಇನ್ಕಮಿಂಗ್ ಪೇಲೋಡ್ (payload) ನಮ್ಮ ಆಂತರಿಕ ಸ್ಟೋರ್ಫ್ರಂಟ್ ಡೇಟಾಬೇಸ್ಗೆ ತಲುಪುವ ಮೊದಲು ವ್ಯಾಲಿಡೇಶನ್ ಮತ್ತು ಮ್ಯಾಪಿಂಗ್ ಹಂತಗಳ ಮೂಲಕ ಹಾದುಹೋಗುತ್ತಿತ್ತು.
ನಾನು ಉತ್ಪನ್ನಗಳು, ವೇರಿಯಂಟ್ಗಳು, ಬೆಲೆ ಇತಿಹಾಸ ಮತ್ತು ಸಿಂಕ್ ಲಾಗ್ಗಳಿಗಾಗಿ ಪ್ರತ್ಯೇಕ ಟೇಬಲ್ಗಳೊಂದಿಗೆ PostgreSQL ಅನ್ನು ರಚಿಸಿದೆ. ಸಪ್ಲೈಯರ್ ಮೌಲ್ಯವನ್ನು ಬದಲಾಯಿಸಿದಾಗ ಅಥವಾ ಸಂಖ್ಯೆಯ ಬದಲಿಗೆ null ಕಳುಹಿಸಿದಾಗ, ಪೈಪ್ಲೈನ್ ಅದನ್ನು ಪತ್ತೆಹಚ್ಚಿ ಸ್ಟೋರ್ಫ್ರಂಟ್ ಡೇಟಾವನ್ನು ಹಾಳು ಮಾಡುವ ಬದಲು ಫೇಲ್ಯೂರ್ ರೆಕಾರ್ಡ್ ಅನ್ನು ಬರೆಯಿತು. ನಾನು ಲಾಗ್ ಸಾಲನ್ನು ನೋಡಿ ಯಾವ ಎಂಡ್ಪಾಯಿಂಟ್ ಕೆಟ್ಟಿದೆ, ಅದು ಯಾವಾಗ ಸಂಭವಿಸಿತು ಮತ್ತು ಯಾವ ಫೀಲ್ಡ್ಗಳು ತಪ್ಪಾಗಿವೆ ಎಂಬುದನ್ನು ನಿಖರವಾಗಿ ತಿಳಿಯಬಹುದಿತ್ತು. ಸಪ್ಲೈಯರ್ ವಾರಾಂತ್ಯದಲ್ಲಿ ತಮ್ಮ API ಅನ್ನು "ಅಪ್ಗ್ರೇಡ್" ಮಾಡಲು ನಿರ್ಧರಿಸಿದಾಗ, ಈ ವೀಕ್ಷಣಾ ಸಾಮರ್ಥ್ಯವು (observability) ನನಗೆ ಹಲವು ಬಾರಿ ಸಹಾಯ ಮಾಡಿತು.
ಯಶಸ್ವಿಯಾದ ಅಂಶಗಳು
ಆಟೊಮೇಷನ್ (Automation) ಹೆಚ್ಚಿನ ಸಮಯವನ್ನು ಉಳಿಸಿತು. ಆರಂಭದಲ್ಲಿ, ನಾನು ಮ್ಯಾನುಯಲ್ ವಿಧಾನವನ್ನು ಪ್ರಯತ್ನಿಸಿದೆ: ಸಪ್ಲೈಯರ್ ಸ್ಪ್ರೆಡ್ಶೀಟ್ಗಳನ್ನು ಡೌನ್ಲೋಡ್ ಮಾಡುವುದು, ಅವುಗಳನ್ನು ಕೈಯಿಂದ ಸ್ವಚ್ಛಗೊಳಿಸುವುದು, ಚಿತ್ರಗಳನ್ನು ಫಾರ್ಮ್ಯಾಟ್ ಮಾಡುವುದು ಮತ್ತು ಸ್ಟೋರ್ಗೆ CSVಗಳನ್ನು ಅಪ್ಲೋಡ್ ಮಾಡುವುದು. ಕ್ಯಾಟಲಾಗ್ ಕೆಲವು ಡಜನ್ ಐಟಂಗಳನ್ನು ಮೀರಿದ ತಕ್ಷಣ ಅದು ಅಸಾಧ್ಯವಾಯಿತು. ಆಟೊಮೇಟೆಡ್ ಪೈಪ್ಲೈನ್ ಹೊಸ ಲಿಸ್ಟಿಂಗ್ಗಳು, ಬೆಲೆ ಅಪ್ಡೇಟ್ಗಳು ಮತ್ತು ಸ್ಟಾಕ್ ಹೊಂದಾಣಿಕೆಗಳನ್ನು ನಾನು ಸ್ಪ್ರೆಡ್ಶೀಟ್ ಮುಟ್ಟದೆಯೇ ನಿರ್ವಹಿಸಿತು.
ಟೆಂಪ್ಲೇಟ್ಗಳ ಮೂಲಕ ಉತ್ಪನ್ನ ವಿವರಣೆಗಳನ್ನು ವಿಸ್ತರಿಸಲಾಯಿತು. ಐದ ನೂರು ಬಹುತೇಕ ಒಂದೇ ರೀತಿಯ ಐಟಂಗಳಿಗೆ ವಿಶಿಷ್ಟವಾದ ವಿವರಣೆಯನ್ನು ಬರೆಯುವುದು ಸುಸ್ಥಿರವಲ್ಲ. ಬದಲಾಗಿ, ನಾನು ಮೆಟೀರಿಯಲ್, ಡೈಮೆನ್ಶನ್ ಅಥವಾ ಬಣ್ಣದಂತಹ ಸಪ್ಲೈಯರ್ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಪಡೆದು ಅವುಗಳನ್ನು ರಚನಾತ್ಮಕ ವಿವರಣಾ ಬ್ಲಾಕ್ಗಳಿಗೆ ಸೇರಿಸುವ ಟೆಂಪ್ಲೇಟಿಂಗ್ ಲೇಯರ್ ಅನ್ನು ನಿರ್ಮಿಸಿದೆ. ಇದರ ಫಲಿತಾಂಶವು ಪರಿವರ್ತಿಸಲು ಸಾಕಷ್ಟು ಸ್ವಚ್ಛವಾಗಿತ್ತು ಮತ್ತು ಸಾವಿರಾರು ಹೊಸ SKUಗಳನ್ನು ಸೇರಿಸಲು ಯಾವುದೇ ಮ್ಯಾನುಯಲ್ ಕಾಪಿರೈಟಿಂಗ್ ಅಗತ್ಯವಿಲ್ಲದಷ್ಟು ಸ್ಥಿರವಾಗಿತ್ತು.
ಬೆಲೆ ಮೇಲ್ವಿಚಾರಣೆಯು (Price monitoring) ನನ್ನ ನಿರೀಕ್ಷೆಗಿಂತಲೂ ಉತ್ತಮವಾಗಿತ್ತು. ಪ್ರಮುಖ ಉತ್ಪನ್ನಗಳ ಬೆಲೆಯನ್ನು ಪತ್ತೆಹಚ್ಚಲು ನಾನು ಲೈಟ್ವೇಟ್ ಮಾನಿಟರಿಂಗ್ ಲೇಯರ್ ಅನ್ನು ನಿರ್ಮಿಸಿದೆ. ಬೆಲೆಯಲ್ಲಿ ಬದಲಾವಣೆ ಕಂಡುಬಂದಾಗ, ನಾನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ ಗಾರ್ಡ್ರೇಲ್ಗಳ ಒಳಗೆ ಸಿಸ್ಟಮ್ ನಮ್ಮ ಮಾರ್ಜಿನ್ಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಹೊಂದಿಸಿತು. ಸಪ್ಲೈಯರ್ ಸಗಟು ಬೆಲೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಿದರೆ, ಲಿಸ್ಟಿಂಗ್ ಬೆಲೆಯು ದಿನಗಳಿಗಿಂತ ನಿಮಿಷಗಳಲ್ಲಿ ಆ ಬದಲಾವಣೆಯನ್ನು ಪ್ರತಿಫಲಿಸಬಲ್ಲದು. ಆ ಸ್ಪಂದನಾ ಸಾಮರ್ಥ್ಯವು ಕಡಿಮೆ ಮಾರ್ಜಿನ್ ಇರುವ ವಸ್ತುಗಳ ಮೇಲೆ ಗಮನಾರ್ಹ ವ್ಯತ್ಯಾಸವನ್ನು ಉಂಟುಮಾಡಿತು.
ಏನೆಲ್ಲಾ ವಿಫಲವಾಯಿತು ಮತ್ತು ಏಕೆ
ಸಪ್ಲೈಯರ್ APIಗಳಲ್ಲಿ ಸ್ಥಿರತೆ ಇರುವುದಿಲ್ಲ. ಇದು ದೂರು ಅಲ್ಲ; ಇದು ಒಂದು ವಾಸ್ತವಿಕ ಸತ್ಯ. ಒಬ್ಬ ಪಾಲುದಾರನು ಮುನ್ಸೂಚನೆ ನೀಡಬಹುದಾದ ಪೇಜಿನೇಶನ್ನೊಂದಿಗೆ ಸ್ವಚ್ಛವಾದ JSON ಅನ್ನು ನೀಡುತ್ತಾನೆ. ಇನ್ನೊಬ್ಬನು ಸೋಮವಾರ camelCase ಟ್ಯಾಗ್ಗಳೊಂದಿಗೆ ಮತ್ತು ಬುಧವಾರ snake_case ಟ್ಯಾಗ್ಗಳೊಂದಿಗೆ XML ಅನ್ನು ನೀಡುತ್ತಾನೆ. ರೇಟ್ ಲಿಮಿಟ್ಗಳು ಉದಾರದಿಂದ ಶಿಕ್ಷಾರ್ಹ ಮಟ್ಟದವರೆಗೆ ಬದಲಾಗುತ್ತವೆ. ಡೌನ್ಟೈಮ್ ಅನ್ನು ಸರಿಯಾದ ಸ್ಟೇಟಸ್ ಕೋಡ್ಗಳ ಬದಲಿಗೆ HTML ಎರರ್ ಪೇಜ್ಗಳ ಮೂಲಕ ತಿಳಿಸಲಾಗುತ್ತದೆ. 2003 ರಲ್ಲಿ ವಿನ್ಯಾಸಗೊಳಿಸಿದಂತೆ ವರ್ತಿಸುವ ಎಂಡ್ಪಾಯಿಂಟ್ಗಳಿಗಾಗಿ ನೀವು ಡಿಫೆನ್ಸಿವ್ ಪಾರ್ಸರ್ಗಳು ಮತ್ತು ರಿಟ್ರೈ ಲಾಜಿಕ್ ಅನ್ನು ಬರೆಯಬೇಕಾಗುತ್ತದೆ.
Inventory sync had race conditions that cost me sleep. Picture this: two customers order the last unit within seconds of each other, or a supplier webhook tells you stock hit zero at the exact moment a buyer clicks checkout. My initial read-then-update logic failed catastrophically. I had to rewrite the sync layer using atomic PostgreSQL transactions and pessimistic locking for high-velocity SKUs. It was a painful, practical lesson in concurrency that no tutorial prepares you for quite like real money on the line.
My biggest failure was ignoring customer support automation. I obsessed over data pipelines and treated the human aftermath as an afterthought. Orders arrived late. Suppliers shipped the wrong color. Customers sent emails that sat in my inbox for hours while I debugged API timeouts. I had no ticket routing, no automated responses, no chatbot handoffs. The technical infrastructure was solid. The human infrastructure was missing, and that gap hurt the business more than a flaky webhook ever did.
Testing Images Like an Engineer
I ran a side experiment on product images. I served different hero images to different users using simple URL parameter routing tied to session-based bucketing. One variant showed the product on a plain white background. Another showed it in a lifestyle setting on an actual desk. I tracked conversion rates for each bucket using basic event logging tied directly to the order flow.
Small changes improved engagement. The lifestyle shots did not always win, but when they did, the lift was meaningful enough to change how I prioritized