Scaling Sans Slowdown

Writing greenfield services without sacrificing velocity or quality

When you start you don’t really understand what you need to build because you don’t fully grok the problem domain so you’ll need to be nimble. Fortunately, you also won’t have many users so you don’t need to worry much about performance, efficiency or scalability. This means you can just use create a single monolithic binary, which allows you to move fast when your team can still fit in one room (4–6 people).

To avoid future pain architect the monolith into modules with strict APIs between them. This will make it much easier to split it up into microservices later if you need to scale out. But for now you still get the benefits of being able to easily change the APIs in a single commit and push a single binary to prod.

If your problem turns out to be worth solving then you will eventually achieve product/market fit and your user base will grow quickly. That’s when you’ll need to scale out in a hurry. Fortunately, you’ve set yourself up well for this.

Extract each module from the monolith into an independent service (or library), starting with the foundational ones whose APIs are most stable already. Peel off engineers from the original team to lead small new teams that will own each new service/lib as it is born. They should get a new room to sit in.

Document the API boundaries between the new service/lib and the monolith. Set up automated integration tests based on the docs. Have them run after every commit. Automatically roll back commits that break them. Create presubmit tests for anything that can be verified quickly. Require that docs & tests are updated along with any changes/additions to the API.

Go on vacation for a few weeks. See if anything broke while you were gone. If so, figure out why & make sure it can’t happen again. Repeat until IPO.