Micro Services

Uber's business starts with google spread sheets. Like many virtual marketplace connecting buyers and sellers in it's early stages, spread sheets get job done. The problem is it's not scalable and employee get burned out quickly when business takes off, "hustle is the antidote"--Travis Fun story during that period was first version of surge pricing was done via spreadsheet and operator manually set a multiplier during peak time.

Uber begin to employe engineers and approach problem with 90s approach. Expand master relational database and put records there, that works well until master database can't handle the load from various of clients. That caused a three days outage where everything handled by cache.

"Let's break it down, MicroServices will save us!" I can't recall exactly how many micro services as well as facade proxy services there. It's around 3K last time I checked. During this period of time, if I ask anyone what's performance bottle neck of their services they owned, I often hear similar answer. "RPC(s) wait too long" For example, if I need to get a trip information, I need to call one service. To get driver of that trip, I need to make another RPC call. To get riders(yet another one) How about city or promotion information(yet yet other ones) Every micro service is optimized to make entity and API as simple as possible yet put lots of burden on caller's shoulder. Those cons come to a point where pricing system can't deal with wait time so they have to simplify logic and yield suboptimal results.

Those cons come to a point where some teams starts to reevaluate data flow efficiency as well as service throughput efficency. From data flow efficiency front, teams devoted time to see how to do team local or centralized cache to shuffle data efficiently and reduce latency of relavant RPC(s); Service throughput front, Golang because of it's light weighted go routine fanout along with channel communication benefits, which offers hundreds of concurrent blocking synchronous calls per host, quickly became popular among many teams.

Back to previous question, MicroServices does help Uber core services achieve high availability and avoid another massive outage from monorepo. What trade off made this front was low consistency and communication efficency across services. Will Golang solve all headaches from MicroServices? Probably not, it does mitigate communication efficency for many typical request response use cases. Low consistency across multiple services requires a greater efforts to loop in teams from many aspect to sit down and layout agreements in great detail. In reality, it is very challenging and error prone in web company with high growth ratio.

In micro services field, "low consistency is the disease, (Commit logs--bottom up knowledge graph-- top down)? is the antidote". I am in favor of bottom up in this case.