Project
Microservices Platform Transition
Product & Growth, Laced
I drove the product requirements and flow mapping for Laced's move toward a service-based architecture, targeting the three domains causing the most coupling pain: pricing, orders, and authentication.
- I untangled legacy flow behaviour, defined service boundaries and contracts from a consumer perspective, and specified edge cases — refunds, partial orders, auth expiry, retry states — so engineering could extract services without breaking existing behaviour.
- Critical checkout flows became more reliable, regressions in pricing and order state reduced, and feature work in those domains became faster and safer to ship.
Overview
As Laced scaled, tight coupling between pricing, orders, and authentication was creating a predictable set of problems: changes in one area broke another, deployment risk grew, and feature velocity slowed because every change required touching multiple systems. This wasn't a decision to do microservices because it was fashionable — it was a risk and throughput problem with a clear business case.
The problem
The coupling had three expensive failure modes. A pricing change could break checkout. An auth change could break order flow. And when something went wrong, it was hard to isolate — the blast radius was large, rollbacks were slow, and debugging was difficult because ownership of state was unclear. Incident postmortems kept pointing at the same root cause.
My role was to own the product requirements side of the migration: define what each service should own, map the real behaviour of existing flows (not the idealised version), and give engineering the inputs they needed to extract services without regressing behaviour.
What I did
I started by identifying which flows to extract first. Not everything should move at once. The right candidates had high change frequency, high business criticality, clear conceptual boundaries, and painful coupling. That analysis pointed to pricing, orders, and authentication — the three domains most likely to cascade failures into checkout.
I then did the flow-mapping work that makes migrations safe: writing out how the system actually behaved (including all the edge cases that don't live in any spec), defining what each service needed to own, and specifying inputs, outputs, failure modes, and data consistency requirements from a consumer's perspective.
Systems I built
Pricing pathway:
- Clarified the full set of pricing inputs and outputs: base price, FX and tax/duties, discounts, shipping, rounding rules
- Eliminated duplicated pricing logic that was producing mismatches between PDP, cart, and checkout
- Enabled isolated changes to pricing without touching order or auth flows
Orders pathway:
- Defined a clean order lifecycle with unambiguous state transitions: created → paid → fulfilled → delivered → returned/refunded
- Resolved inconsistent "ghost states" caused by multiple systems touching order status
- Improved observability — failures in order state became diagnosable without guessing which system was the source
Auth pathway:
- Mapped auth propagation through the funnel (sessions, permissions, account state)
- Reduced coupling where auth changes were causing unrelated purchase journey failures
- Made future onboarding and permissions changes safer to ship
Rollout approach:
- Incremental cutovers, not a big bang
- Feature flags for new pathways with parallel-run capability during transition
- Contract testing and explicit error handling at service boundaries
- Monitoring dashboards around pricing mismatches, order state errors, and auth failures
Impact
Regressions in critical checkout flows decreased. Fewer incidents were caused by changes in pricing or auth cascading into unrelated areas. Diagnosis time when issues did occur improved because ownership was clearer. Feature work in the three extracted domains became faster and lower-risk to ship — which was the original goal.