Promotions Retrieval Redesign

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

The problem

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.

What I did

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.

Stack