Dropbox spent about four years rebuilding its desktop sync engine from scratch and shipped the replacement, Nucleus, to all users in 2020. The engineer who wrote it up said plainly that in many environments it would have been a terrible idea. What was true at Dropbox that made a four-year from-scratch rewrite the maintainable choice rather than the reckless one, and what did it cost?

The situation they were in

Sync is the product. Dropbox's own write-up describes a legacy engine that used threading freely and could pass through invalid intermediate states on the way to a supposedly legal final state. That property is what made it unmaintainable, because if the set of reachable states cannot be enumerated it cannot be asserted on, so 100% of changes shipped with a correctness review by whoever remembered the most. The replacement binds all control tasks to a single thread with only I/O and hashing on background threads, and represents sync as three trees - remote filesystem state, local filesystem state, and last known fully synced state.

Read as a delivery-versus-maintainability decision, the constraint was never performance. It was the tax every future change paid, and the currency that tax was paid in was data loss.

What made it defensible

• The component had a specification that could be written down exactly. Sync has invariants - what must be true of those three trees - independent of the existing implementation. This is the rare case where the old code is not the specification.
• The invariants were expressible in a type system, so Rust could make invalid states unrepresentable rather than merely tested for.
• The real investment was testing, not language. The post is explicit that swapping the engine on hundreds of millions of machines required a serious automated testing programme, and credits that programme with letting the team keep shipping features on a normal release cadence during the rebuild.
• The old engine kept running the business throughout, so the decision stayed reversible until the switch.

What it cost

Four years of a team's capacity, a second implementation to maintain in parallel, and a swap performed mid-flight on hundreds of millions of installs. The cost of being wrong was not a rollback; it was corrupting customers' files.

Where copying it is a mistake

A rewrite is defensible when the component has a specification you can state exactly and the failure mode is correctness. It is reckless when the specification is "whatever the old system does" - which describes most business applications, where accumulated behaviour is the requirement and a strangler migration is the only honest route. A team that cannot fund a differential test harness is choosing to discover the specification in production.

Two usable rules come out of this. First: choose a rewrite only if the component's invariants fit on one page, and otherwise choose a strangler migration. If they do not fit, the deliverable for the next quarter is that page, not code. Second, compare the rewrite's cost against the annual tax the current design charges, measured as the share of changes that need a correctness review. A four-year rebuild needs a tax measured in large fractions of the team's output and a consequence measured in data loss. Developer irritation, an unfashionable language and a difficult codebase do not clear that bar, and they are the three reasons most rewrites are actually proposed.

Common weak answers

• "They rewrote it in Rust and that is why it worked." The language made invalid states unrepresentable, which mattered - but the testing programme is what made the swap survivable, and the author says so.
• "Big companies can afford rewrites." The budget was not the deciding factor. The existence of a precise, implementation-independent specification was, and no budget creates one.
• "This proves rewrites beat incremental migration." It proves the opposite for almost everyone. The author's own caveat - that in many environments it would have been a terrible idea
• is the part of the story most readers skip.