case study 04 · 2026 · sole author of the routing module

Many stores behind one WhatsApp number

Merchants with a group of related stores wanted one WhatsApp business number for all of them, with different rules about what a retailer can see and where they get registered. The engine assumed one number meant one store.

routing module: sole author279 lines
rules: 4 × 4visibility by registration
caches: 2 layers5 min and 30 min
regressions: 0for single-store customers

inbound messagenumber      -> subscription config        cached 5 min
config      -> visibility × registration  4 × 4, illegal pairs refused
retailer    -> their store(s)             cached 30 min, negative cache for salesmen
any failure -> single-store behaviour       the path that existed before

Every step has a fallback, and the fallback is the old behaviour.

the claim

"One number, one store" was baked into how every inbound message was routed: catalogue, cart, pricing and order all assumed it.

what I built

A routing module that resolves which stores a message can see and where the retailer gets registered, from a visibility rule (all, related, one, or secondary only) crossed with a registration rule (automatic primary, automatic all, retailer picks, or none). Sixteen combinations, stored as JSONB.
Illegal combinations are refused server-side. Wide visibility with primary-only registration would let a retailer browse every store and order from one, so the API won't accept it.
A retailer-picks mode that asks the retailer which store to use, inside WhatsApp itself.
Two cache layers, config for 5 minutes and the retailer's store for 30, with a negative-cache marker for salesmen who will never match.

what changed

Every failure path degrades to the behaviour that existed before the feature shipped, so single-store subscriptions saw zero change by construction. More on the platform side in One WhatsApp number, many stores.