今天這篇文章探討的是 Uber 內部的架構以及系統設計。
Uber 最初是使用 Python 作為開發語言，並且基於 monolithic 的架構來開發前後端。 2014 之後，Uber 將架構給轉移到 service-oriented 的架構。
Uber 的業務(Taxi,Eats)基本上是一種 Demand <---> Supply 邏輯的業務，以叫車服務就是如何將叫車的使用者與開車的司機給媒合。基於業務可以分類出系統需要兩個服務，分別是
Deman 服務以及 Supply 服務。
這兩個服務會串接系統內的 DISCO(Dispatch Optimization)， 該服務基於 Map&Location 等資料來進行處理，但是這兩種資料搭配經緯度要處理實在麻煩，因此該服務使用 Google S2 函式庫來處理。
文章中介紹非常多 DISCO 如何處理地點相關的資料，如何有效率地幫司機跟使用者給媒合，有興趣的可以
點選原文閱讀。
除了媒合系統外，文章中還介紹了如何處理 Payment fraud 這類型的問題，全文非常長，有興趣的可以細讀
而這邊列出文章提到的各種專案
1. PostgreSQL -> MySQL (文章中有另外一篇連結探討為什麼轉移)
2. RDBMS/HDFS
3. KAFKA
https://medium.com/nerd-for-tech/uber-architecture-and-system-design-e8ac26690dfc
