Uploaded byC4Media
Scaling Uber
The document provides an overview of InfoQ, highlighting its monthly visitor statistics, multilingual content, and significant coverage of QCon conferences. It describes Uber's engineering history, technological evolution, and strategies for scaling and managing service architecture, including challenges like latency and microservices. Additionally, it emphasizes the importance of empowering software development and innovation through community engagement and knowledge sharing.
More Related Content
Scaling Uber
- 1.
- 2. InfoQ.com: News &Community Site • 750,000 unique visitors/month • Published in 4 languages (English, Chinese, Japanese and Brazilian Portuguese) • Post content from our QCon conferences • News 15-20 / week • Articles 3-4 / week • Presentations (videos) 12-15 / week • Interviews 2-3 / week • Books 1 / month Watch the video with slide synchronization on InfoQ.com! http://www.infoq.com/presentations /uber-scalability-arch
- 3. Purpose of QCon -to empower software development by facilitating the spread of knowledge and innovation Strategy - practitioner-driven conference designed for YOU: influencers of change and innovation in your teams - speakers and topics driving the evolution and innovation - connecting and catalyzing the influencers and innovators Highlights - attended by more than 12,000 delegates since 2007 - held in 9 cities worldwide Presented at QCon San Francisco www.qconsf.com
- 4. As of November2015: Uber Cities Worldwide: 356 Countries: 65 Employees: 4,800 Engineers: 1,500 US Driver Payments in 2015: $3.5B
- 7.
- 8. 2009-2010 Outsourced PHP+ MySQL Jan 2011 "dispatch" - Node.JS/MongoDB Jan 2011 “API” - Python/SQLAlchemy/MySQL Feb 2012 Dispatch swaps MongoDB for Redis May 2012 Dispatch adds ON fallback Jan 2013 First non-API Python services Feb 2013 API switched to Postgres Mar 2014 New Python services use MySQL Mar 2014 Schemaless begins, must finish before pg collapse Sep 2014 First Schemaless - trips out of Postgres Aug 2015 Dispatch X.0 / Ringpop / Riak
- 9.
- 10.
- 12.
- 13.
- 14.
- 36. Getting out ofthe HTTP+JSON business HTTP is slow, complex, and inconsistent JSON is hard to validate, awkward in non-node Thrift is OK, but generated code is bad
- 39.
- 41. Lots of services,lots of instances Mostly Node.JS and Python Call graph unknowable Self-inflicted DoS Cascading failures
- 49. load balancerservice A serviceB service B
- 50. load balancer service Aservice B service B
- 51. horizontal scalability zipkin tracing circuitbreaking rate limiting failure testable almost no configuration as available as possible
- 52. overall latency ≥latency of slowest component 1ms avg, 1000ms p99 use 1: 1% at least 1000ms use 100: 63% at least 1000ms 1.0 - 0.99^100 = 0.634 = 63.4% LATENCY
- 53. requeststhatareslow 0% 25% 50% 75% 100% Processes Used 1 24 8 16 32 64 128 256 512 1024 p95 p99 p99.9
- 57.
- 58.
- 59.
- 60. partner app dispatchDC1 Location Updates State Digest dispatch DC2 Location Updates State Request
- 63.
- 64.
- 65.
- 66. Watch the videowith slide synchronization on InfoQ.com! http://www.infoq.com/presentations/ uber-scalability-arch