--- title: The Engineering Behind Uber’s Real-Time Maps | daily.dev description: An explanation of how Uber's real-time map handles millions of GPS location updates per second by splitting the system around read patterns rather than writes.... canonical: https://daily.dev/posts/the-engineering-behind-uber-s-real-time-maps-hlmfmjnlg twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: The Engineering Behind Uber’s Real-Time Maps | daily.dev og:description: An explanation of how Uber's real-time map handles millions of GPS location updates per second by splitting the system around read patterns rather than writes.... og:url: https://daily.dev/posts/the-engineering-behind-uber-s-real-time-maps-hlmfmjnlg og:image: https://api.daily.dev/og/posts/hLMFMjNlG.png og:image:alt: The Engineering Behind Uber’s Real-Time Maps og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # The Engineering Behind Uber’s Real-Time Maps **[ByteMonk](https://daily.dev/sources/bytemonk)** · 11 min read · 39 upvotes · 2 comments ## Summary An explanation of how Uber's real-time map handles millions of GPS location updates per second by splitting the system around read patterns rather than writes. Covers an edge ingestion layer that validates, deduplicates, and adaptively samples pings before they hit a database; H3, Uber's open-sourced hexagonal geospatial index, which turns 'find nearby drivers' from a full scan into a bounded lookup; a fast in-memory store (Redis-like) for live rider map queries paired with a durable Cassandra-family store for analytics and pricing; conditional updates to prevent double-booking a driver; heartbeat-based handling of drivers going offline at airports; and client-side Kalman filtering plus map matching to smooth jittery GPS data into a believable moving dot. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What is H3 and why did Uber build it for finding nearby drivers? H3 is a geospatial indexing system Uber built and later open-sourced that slices the planet into hexagonal cells, each with a unique ID, so every driver maps to the cell they currently occupy. Finding nearby drivers becomes a lookup inside a cell and its neighbors instead of a full scan. Hexagons are used because every neighboring cell sits at an equal distance from the center, unlike squares where diagonal neighbors are farther, keeping distance and range calculations consistent. _Engineers researching geospatial indexing choices for location-based apps can track H3 adoption patterns on daily.dev._ ### Why can't a single relational database handle Uber's driver location updates? A single well-tuned relational database tops out at tens of thousands of writes per second, far below the up to 5 million location pings per second generated by active drivers. Beyond write throughput, the deeper problem is that three different consumers (the rider's map, the matching engine, and the pricing analytics pipeline) each need the same location data in a different shape and latency profile, which no single datastore serves well simultaneously. _Teams designing high-throughput location systems can follow similar scaling tradeoffs on daily.dev._ ### How does a system prevent two riders from being matched to the same driver at once? The driver record is updated with a conditional write that changes the status from available to reserved only if it is still available at the moment of the update, making the check-and-set an atomic database operation so only one of the two competing requests succeeds. If the winning request's offer later expires, the reservation is released only if it still belongs to that specific offer, preventing a delayed timeout from clearing a newer reservation. _Developers building reservation or booking systems can track atomic concurrency patterns like this on daily.dev._ ## Community discussion Top comments from developers on daily.dev. **@ajaychoudhary80** · 1 upvotes > The key insight is designing around read patterns, not just scaling writes. Combining H3 for bounded spatial lookups, an in-memory layer for live queries, and durable storage for historical data shows how different workloads deserve different architectures. The client-side Kalman filtering and map matching are a great reminder that perceived real-time accuracy matters just as much as raw throughput. **@yaireo** · 1 upvotes > Waze has been doing that since forever.. ## Similar posts on daily.dev - [How Uber Serves over 150 Million Reads per Second from Integrated Cache](https://daily.dev/posts/how-uber-serves-over-150-million-reads-per-second-from-integrated-cache-mjlsygxjr) · ByteByteGo · 218 upvotes · 5 comments - [30\+ Updates per Second per Account: Uber Scales Ledger Processing with Batching](https://daily.dev/posts/30-updates-per-second-per-account-uber-scales-ledger-processing-with-batching-h5w2zvquh) · InfoQ · 0 upvotes · 0 comments - [Unlocking real-time geospatial intelligence \| Elastic](https://daily.dev/posts/unlocking-real-time-geospatial-intelligence-elastic-ugxqu2l6x) · elastic · 0 upvotes · 0 comments - [Uber wants to turn its millions of drivers into a sensor grid for self-driving companies](https://daily.dev/posts/uber-wants-to-turn-its-millions-of-drivers-into-a-sensor-grid-for-self-driving-companies-iz0shhfwy) · TechCrunch · 0 upvotes · 0 comments --- Tags: [#career](https://daily.dev/tags/career), [#uber](https://daily.dev/tags/uber) [View this post on daily.dev](https://daily.dev/posts/the-engineering-behind-uber-s-real-time-maps-hlmfmjnlg) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"The Engineering Behind Uber’s Real-Time Maps","url":"https://daily.dev/posts/the-engineering-behind-uber-s-real-time-maps-hlmfmjnlg","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/the-engineering-behind-uber-s-real-time-maps-hlmfmjnlg"},"datePublished":"2026-10-16T04:10:46.883Z","dateModified":"2026-10-16T04:11:07.957Z","description":"An explanation of how Uber's real-time map handles millions of GPS location updates per second by splitting the system around read patterns rather than writes....","image":"https://i.ytimg.com/vi/R_wWbHqpQTg/sddefault.jpg","thumbnailUrl":"https://i.ytimg.com/vi/R_wWbHqpQTg/sddefault.jpg","isAccessibleForFree":true,"articleSection":"ByteMonk","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"ByteMonk","logo":"https://media.daily.dev/image/upload/s--n36_-Uve--/f_auto/v1752670492/logos/bytemonk","url":"https://daily.dev/sources/bytemonk"},"commentCount":2,"discussionUrl":"https://daily.dev/posts/the-engineering-behind-uber-s-real-time-maps-hlmfmjnlg","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":39},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":2}],"keywords":"career,uber","timeRequired":"PT11M","video":{"@type":"VideoObject","name":"The Engineering Behind Uber’s Real-Time Maps","description":"An explanation of how Uber's real-time map handles millions of GPS location updates per second by splitting the system around read patterns rather than writes....","thumbnailUrl":"https://i.ytimg.com/vi/R_wWbHqpQTg/sddefault.jpg","uploadDate":"2026-10-16T04:10:46.883Z","duration":"PT11M","url":"https://api.daily.dev/r/hLMFMjNlG","embedUrl":"https://www.youtube.com/embed/R_wWbHqpQTg"}} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"ByteMonk","item":"https://daily.dev/sources/bytemonk"},{"@type":"ListItem","position":3,"name":"The Engineering Behind Uber’s Real-Time Maps"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/the-engineering-behind-uber-s-real-time-maps-hlmfmjnlg","comment":[{"@type":"Comment","text":"The key insight is designing around read patterns, not just scaling writes. Combining H3 for bounded spatial lookups, an in-memory layer for live queries, and durable storage for historical data shows how different workloads deserve different architectures. The client-side Kalman filtering and map matching are a great reminder that perceived real-time accuracy matters just as much as raw throughput.","datePublished":"2026-10-17T00:38:06.150Z","url":"https://daily.dev/posts/hLMFMjNlG#c-xKQSo5ki1","author":{"@type":"Person","name":"Ajay Choudhary","url":"https://daily.dev/ajaychoudhary80","image":"https://media.daily.dev/image/upload/s--WkX8wDW2--/f_auto/v1780989706/avatars/avatar_QNZlI2SgVnNSx5PSRpCVx?_a=BAMAMiWQ0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1}},{"@type":"Comment","text":"Waze has been doing that since forever…","datePublished":"2026-10-17T07:57:37.847Z","url":"https://daily.dev/posts/hLMFMjNlG#c-b2xOmXmX5","author":{"@type":"Person","name":"Yair Even Or","url":"https://daily.dev/yaireo","image":"https://avatars.githubusercontent.com/u/845031?v=4"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/the-engineering-behind-uber-s-real-time-maps-hlmfmjnlg#faq","mainEntity":[{"@type":"Question","name":"What is H3 and why did Uber build it for finding nearby drivers?","acceptedAnswer":{"@type":"Answer","text":"H3 is a geospatial indexing system Uber built and later open-sourced that slices the planet into hexagonal cells, each with a unique ID, so every driver maps to the cell they currently occupy. Finding nearby drivers becomes a lookup inside a cell and its neighbors instead of a full scan. Hexagons are used because every neighboring cell sits at an equal distance from the center, unlike squares where diagonal neighbors are farther, keeping distance and range calculations consistent. Engineers researching geospatial indexing choices for location-based apps can track H3 adoption patterns on daily.dev."}},{"@type":"Question","name":"Why can't a single relational database handle Uber's driver location updates?","acceptedAnswer":{"@type":"Answer","text":"A single well-tuned relational database tops out at tens of thousands of writes per second, far below the up to 5 million location pings per second generated by active drivers. Beyond write throughput, the deeper problem is that three different consumers (the rider's map, the matching engine, and the pricing analytics pipeline) each need the same location data in a different shape and latency profile, which no single datastore serves well simultaneously. Teams designing high-throughput location systems can follow similar scaling tradeoffs on daily.dev."}},{"@type":"Question","name":"How does a system prevent two riders from being matched to the same driver at once?","acceptedAnswer":{"@type":"Answer","text":"The driver record is updated with a conditional write that changes the status from available to reserved only if it is still available at the moment of the update, making the check-and-set an atomic database operation so only one of the two competing requests succeeds. If the winning request's offer later expires, the reservation is released only if it still belongs to that specific offer, preventing a delayed timeout from clearing a newer reservation. Developers building reservation or booking systems can track atomic concurrency patterns like this on daily.dev."}}]} ```