Monolith to services in high-volume grocery fulfilment
How grocery retailers modernise ordering and warehouse fulfilment without freezing change for a year-long rewrite.
Rewrite pressure meets weekly trading reality
Grocery fulfilment platforms sit on critical paths: slot booking, picking, inventory, and last-mile promises. A big-bang rewrite freezes product for too long and concentrates risk into a single cutover weekend.
A safer pattern is strangler evolution: identify the highest-churn or highest-risk capability, extract a clear service boundary, and keep the monolith as the system of record until the new path proves itself under real volume.
Boundaries that match the warehouse
Service cuts that mirror org charts fail. Cuts that mirror fulfilment stages — catalogue and availability, order capture, pick path, despatch — survive contact with operations. Each boundary needs an explicit data owner and a failure story (what the store or customer sees when that service is degraded).
Keep observability ahead of decomposition
If you cannot see order lag, pick exceptions, and inventory mismatches today, microservices will only multiply the blind spots. Instrument the monolith first, then extract — so each new service inherits a clear SLO instead of inventing one after the first incident.
Related: Sainsbury's fulfilment case study