This was the largest technical project I led. The search system had become a monolith that was too slow to change — deployments were risky and infrequent, bugs in one area could affect unrelated functionality, and scaling specific bottlenecks meant scaling everything.
Deciding where to cut
The hardest part of breaking up a monolith is not the implementation — it's deciding on the architecture. Where do the service boundaries go? Get this wrong and you've traded one set of problems for a more expensive one.
I ran architecture sessions with the team: we mapped the existing system, identified the natural seams, and worked through the failure modes of different boundary choices. We looked at how other companies had handled similar migrations and consulted senior engineers elsewhere at CafeBazaar. Eventually we had a design everyone could commit to. We shipped it incrementally — replacing one component at a time, validating each step, until the monolith was fully retired.
The caching system
As part of the migration, we redesigned the caching layer. Each Kubernetes pod had a sidecar running local Redis, backed by a larger shared Redis instance, with a persistent layer for restart resilience. Cache keys encoded multiple parameters (query, filters, page), and each layer had a different TTL. The result was a significant reduction in latency and database load during peak traffic — measurable and meaningful for a system handling millions of daily requests.