Dropbox tried breaking its 3-million-line Python monolith into services, decided most teams shouldn't run services at all, and built a managed platform instead.

Dropbox serves more than 700 million registered users generating at least 300,000 requests per second. Most of its server-side product code lives in a monolithic Python web application called Metaserver — more than 3 million lines, created in 2007 by one of the co-founders. About half of all commits to the server repository modify it.

Around it, platform-level components like authentication, metadata storage, filesystem, and sync had already been split off into their own services. Dropbox describes the result as a solar system: services orbiting a monolith that still serves a lot of the product.

Metaserver’s code was organized the way a small open source project is — library, model, controllers — with no centralized curation. Multiple teams worked on it and no single team owned its quality, so a team needing to unblock a feature would introduce an import cycle rather than refactor. That shipped faster and compounded.

Dropbox’s first answer was the obvious one: a Service Oriented Architecture push. Make it easy to build services outside Metaserver, then carve Metaserver into services owned by the teams that wrote them.

After more than a year and a half, they were well into the first milestone — and that experience exposed the flaw in the second. As more teams and services entered the critical path for customer traffic, maintaining a high reliability standard got harder, and the problem would only compound as they moved up the stack and asked product teams to run services. So the question became sharper than “monolith or microservices”: which parts of the product actually need an independently operated service, and which just need a place to put some logic?

Dropbox divided product functionality in two. Large, complex systems — the logic around sharing a file, with its access control, rate limits, and quotas — should keep being their own services, run by teams large enough to sustain them. Small, self-contained functionality — the homepage, essentially a wrapper around the metadata store — should not. It is unnecessary overhead for a product team to plan capacity, set up alerts, and configure multihoming for that.

Atlas is the platform for the second category. Developers write only the interface and implementation of their endpoints; Atlas creates the production cluster and the Atlas team owns pushing to and monitoring it. Routes are grouped into Atlasservlets — more than 200 of them across more than 5000 routes — each with a private directory, a single owner, and Bazel visibility rules preventing anyone else from importing it. Every Atlasservlet is its own cluster, so it can be pushed and rolled back on its own, and a misbehaving route only hurts routes owned by the same team.

Atlas serves more than 25% of previous Metaserver traffic today, with the rest validated in tests. But Dropbox’s own single most important takeaway is not about the platform: it is that well-thought-out code composition, early in a project’s life, is essential. The part they call the most strategically effective was dismantling the import cycles and splitting the code into feature-based directories — a job that took several years of scripts, grunt work, and refactoring — because it stopped new code from making the problem worse.

The execution philosophy was stepping stones, not milestones: every increment had to deliver value even if the next step failed. They sped up Metaserver’s test frameworks first. They shipped memory efficiency to Metaserver rather than tying it to the Atlas rollout. They started Atlas on internal gRPC to de-risk the serving stack before touching gRPC-HTTP transcoding.

Developers don’t care whether they’re in a monolith or a service — they care about the lowest-overhead path to shipping, and Dropbox’s bet is that you can hand them isolation and fast pushes without also handing them a pager.