Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Gids conference-talk-2019-madan-thangavelu


Published on

A talk on building applications with magical user experiences on cellular mobile networks. We discuss an application protocol developed within Uber to make mobile experiences realtime and responsive.

Find me @

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

Gids conference-talk-2019-madan-thangavelu

  1. 1. Magical User Experiences On Cellular Mobile Networks Marketplace Platform ❏ Madan Thangavelu ❏ Nilesh Mahajan
  2. 2. 01 Introduction to Uber’s Marketplace Platform 02 Uber app experience challenges 03 How did we solve these problems? 04 Insights Agenda
  3. 3. Introduction to Marketplace Platform Team
  4. 4. Goal Extensible platform for reliably moving people and things
  5. 5. Real-Time Communications Geographical Awareness High Global Availability Logistics Modeling Open Platform Development Problem areas we work on
  6. 6. “Building systems at Uber-scale”
  7. 7. Rider/Core Flow Home Enter Destination Request Ride Dispatch Driver Enroute Shopping Ordering Processing Fulfilling
  8. 8. State Machines Rider State Machine Driver State Machine
  9. 9. Synchronize Rider State Machine Driver State Machine
  10. 10. Uber App Experience Challenges ● Time-to-launch app critical on 3G or slower networks ● Synchronize across multiple apps (driver, rider) ● Over tens of parallel RPC request to load various features at app launch, all competing for resources ● Network used is usually cellular and not WiFi ● Polling is expensive ● Polling payloads change less frequently ● Best polling frequency of N second. ● Higher data consumption
  11. 11. How did we solve these problems?
  12. 12. Key Choices ● Moving from sync to async architecture ○ Use of reactive pattern inside apps ○ Reducing blocking network call dependencies ● Reduce client-server interactions ○ Moving from poll to push
  13. 13. Components of a Push System Trigger Service API Layer Push Server App Pushes consumer When to Push? What to Push? How to Push?Triggers
  14. 14. Push Protocols Long Polling ● Work with our HTTP proxies ● Available in browsers ● Simple client implementations Server Sent Events ● SSE has fewer reconnect roundtrips, ● Lower latency Client Server CONTINUE CONNECT MSG 45 Sec MSG CONNECT CONNECT CONNECT Client Server CONNECT MSG MSG MSG MSG Long Polling Server Sends Events
  15. 15. Leveraging Server Sent Events ● Advantages ○ Simple to implement and understand ○ Works on top of HTTP ● Challenges ○ Unidirectional ○ No Visibility ○ Hard to detect broken connections
  16. 16. Introducing Ramen ● Real-time Asynchronous MEssaging Network ● HTTP SSE-based push protocol ● Ensures at least once delivery of a push message ● Optimizes amount of data transfer
  17. 17. Ramen Protocol App Ramen Server /connect?seq=0 Message1,seq=1 Message2,seq=2 /connect?seq=2 Message3,seq=3 Message3,seq=3 Ramen Session Connect Reconnect HTTP 200 (text/event-stream) HTTP 200 (text/event-stream) Ack seq=2
  18. 18. Ramen Protocol continued.. ● Heartbeats every 5 seconds to detect connection failure ● Message acknowledgement every 30 seconds ● Push message wire priority ○ High ○ Medium ○ Low
  19. 19. How speed up app launch? ● App launch process ○ App establishes a Ramen connection with server ○ App make one request to backend - /app/launch ■ Endpoint returns 1 MTU (1500 bytes)-sized response ■ /app/launch also acts as a async trigger to our push systems ○ Based on back-end user state, server generates tens of pushes ○ Pushes are sent on Ramen connection by their priority ○ Based on data in push, experience is rendered on the mobile side
  20. 20. Network Pattern App API Gateway App API Gateway Push Server Ramen Pushes High Medium Low Trigger /app/launch connect Before After
  21. 21. 60% reduction 26% reduction 89% reduction 78% reduction vs Poll : vs Ramen v1 : P99 End-to-End Latency
  22. 22. How did we make the entire app more responsive? ● App launch process ○ App establishes a Ramen connection with server ● On any state machine change ○ Kafka events trigger the push systems ○ Based on type of event and backend state, pushes are generated ○ Pushes are sent over the Ramen connection ● All polling calls were changed to push ● Larger pushes were broken down to smaller pushes ● Enforcement and education about payload sizes
  23. 23. Concurrent Connections 1M+ Types of apps 20+ Messages Streamed Per Second 100K+ Messages Delivered for Driver app 99% Rider Driver Uber Lite Uber Eats Restaurants Uber Fleet Uber Freight Web Jump Bikes Insights
  24. 24. Thank you !
  25. 25. Proprietary and confidential © 2019 Uber Technologies, Inc. All rights reserved. No part of this document may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage or retrieval systems, without permission in writing from Uber. This document is intended only for the use of the individual or entity to whom it is addressed and contains information that is privileged, confidential or otherwise exempt from disclosure under applicable law. All recipients of this document are notified that the information contained herein includes proprietary and confidential information of Uber, and recipient may not make use of, disseminate, or in any way disclose this document or any of the enclosed information to any person other than employees of addressee to the extent necessary for consultations with authorized personnel of Uber.