Monolith to microservices, without stopping the auctions
Six years as lead engineers on a real-time used-car auction marketplace taught us how to re-architect a system that is never allowed to stop.
A live auction platform is a hostile place to change architecture. Bids arrive in seconds, money is on the line, and there is no quiet weekend to swap the engine.
Over six years with Nettbil we did exactly that, and the auctions never stopped. The rule that made it possible: cut along business seams, never technical ones.
Cut where the business already divides
An auction, a valuation, a settlement — each is a boundary the business already understands, so each could move out of the monolith on its own schedule and with its own rollback plan.
- One service at a time, each behind its own switch
- A rollback plan written before the migration, not after the incident
- Shadow reads first, then 1% of traffic, then the rest — the old path stays live until the new one has carried real load
Move the platform before the services
Halfway through we moved production onto a managed container platform and kept the whole cloud estate in code.
The order matters. The migration produced twenty-odd deployable units; without platform automation first, each one would have added operational drag instead of removing it. A dedicated QA environment in front of production and monitoring behind it meant every extracted service had to prove itself before and after each deploy.
The team is the other migration
Architecture scales only as fast as the team that owns it. As services appeared, we mentored new engineers and gave each of them a service to run.
Migrate the code but not the team and you have a distributed monolith with more pagers.