sr228822

ironically, I was backend at Uber 2014 - 2018 and used to ask a simple version of implementing an excel formula engine as my go-to coding interview question. Its got a nice mix of data-structures, algorithms, complexity, and implementation. Good candidates can get a reasonably efficient implementation handling cell references in an hour.

nice read. made me nostalgic for the wild days of Uber-China hacking.

Not sure where you got those numbers from.

These articles quote the number of active drivers at 1.5-3 million (end of 2017), which would come out to 40k-80k per driver

http://www.businessofapps.com/data/uber-statistics/#3 https://therideshareguy.com/how-many-uber-drivers-are-there/

A interesting article with some good points. I think the important takeaway is understanding that monoliths are probably better for smaller companies, with less total code, and fewer total engineers. At small scales, the "costs" of microservices (network overhead, distributed transaction management, RPC complexity, dev-environment complexity) outweigh any benefits. A monolith lets you develop quickly, pivot, easily build cross-domain features, and is more efficient up to a point.

That said, I believe there is a point where monoliths begin to break down.

First, It is tough to keep code well structure in a monolith, and eventually things bleed between domains. That means, as mentioned, engineers must understand the entire codebase. This isn't practical for 100k+ LOC codebases. Strict boundaries, in the form of interfaces, limit the scope of code that every engineer must understand. You probably still need gurus who can fathom the entire ecosystem, but a new eng can jump into one service and make changes.

Second, deployment is a mess with any more than a few hundred engineers on a given code base.

Third, it becomes increasingly difficult to incrementally upgrade any part of your tech stack in a monolith. Large monoliths have this tendency to run on 3-year-old releases of everything. This has performance and security implications. It also becomes difficult to changes components within your monolith without versioned interfaces.

Fourth, failure isolation is much harder in a monolith. If any portion of code is re-used between components, thats a single point of failure. If your monolith shares DBs or hardware between components, those are also points of common failure. Circuit-breaking or rate-limiting is less intuitive inside of a monolith then between services.

TLDR; start with a monolith, migrate to micro-services when it becomes too painful.