Srajan Pathak

Staff Engineer — end-to-end owner, RFC author & technical lead

Product-level deals (BOGO, % off) and checkout-level deals (free delivery, service-fee discounts) were served through one generalized model and a single API that returned every promotion for a list of stores — so the storewall loaded ~200 stores just to show two badges each, and catalog views fetched all promos up front, leaning on a client SDK to match promos to products that slowed every client release.

I authored the RFC to split promotions into two first-class domains — ProductPromotions and CheckoutPromotions — redesigned the schema, and introduced three purpose-built, indexed APIs. I ran it as a phased, fully backward-compatible migration: dual-writing old and new models before cutover, moving promo-to-product matching server-side to retire the client SDK, and caching the hot storewall path. Cutting latency this far let promotions graduate from a best-effort tier-2 dependency — dropped on timeout — to a reliable service shown to every user.

Staff Engineer — RFC author, design & delivery

Large grocery partners run flat-price deals on thousands of individual products daily, but there was no practical way to model them — the portal required a separate form per product, so those deals never reached the app and customers went in-store for them, leaving store and app prices inconsistent.

I authored the RFC for a public bulk-ingestion API: partners push their entire promotion list in one call, a thin synchronous front persists it to S3, emits a Kafka event, and returns a job ID, while a horizontally scalable async worker pool validates and creates the promotions. The bottleneck was the per-product conflict check — a heavy multi-table join whose cost grew with the dataset, so lag compounded with every new partner. I re-architected it onto a purpose-built denormalized, composite-indexed table (written transactionally with the source of truth), turning each check from a linear scan into a near-constant index seek — so ingestion latency stopped scaling with partner count. End-to-end lag dropped from ~6 hours (8 a.m. submissions live at 2 p.m.) to under 10 minutes even at peak, keeping the app in sync with in-store pricing.

Program lead — migration strategy & growth-platform delivery owner

The growth platform had to migrate onto the group's central promotions backend — the one other brands already ran on — without disrupting live deals. It looked like a data migration and was not one: the central platform did not yet support some of the promotion types being migrated or the EU price-transparency rules the markets require, so those capabilities had to be added there first, and every consumer surface (catalog, storewall, store view, pricing, checkout) was affected — spanning roughly seven teams across two companies.

I owned the program end to end and led a four-engineer team that migrated the promotion data and adapted the BFF services to consume the new backend. I turned an ambiguous "migrate everything" mandate into a phased, vertical-by-vertical plan — nothing moved big-bang, each capability migrated behind a fully working system and rolled out market by market. In parallel I drove the central-platform team to add the capabilities the migration needed — including EU Omnibus price-transparency compliance, the regulatory blocker gating every European market — as additive features that did not disturb the brands already live on it. I ran a weekly lead sync across all seven teams, aligned PMs and EMs on both sides, and traveled on-site to unblock the hardest cross-company dependencies. We migrated eight promotion types across grocery and food and rolled out across every market with zero disruption to live promotions — surfacing and re-baselining each dependency delay transparently along the way.