# lyft Published articles for lyft. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Refreshing the Travel-Time Map Behind Lyft's Marketplace: Rebuilding Neighborhood Reachability... DevFeed: [Refreshing the Travel-Time Map Behind Lyft's Marketplace: Rebuilding Neighborhood Reachability...]() Original publisher: [Read original article]() Author: Manjunath Shettar Published: 2026-09-10T16:12:28Z Content type: article Language: en Sources: [Lyft Engineering - Medium]() Topics: [dataset](), [airflow]() Tags: [airflow](), [data-processing](), [feature-engineering](), [latency](), [lyft](), [offline](), [tea]() ### AI overview Lyft describes rebuilding its Neighborhood Reachability Signals: offline, regional travel-time matrices between geohash-6 cells and their associated neighborhood-center lists. The refresh replaces older static data and is intended to support marketplace pricing, driver guidance, and demand heatmaps, with future work aimed at time-aware travel times. ### Source excerpt Refreshing the Travel-Time Map Behind Lyft's Marketplace: Rebuilding Neighborhood Reachability Signals Every time Lyft calculates pricing to balance a market, nudges a driver toward an under-served pocket of a city, or paints a heatmap of where demand is building, there is a quiet lookup table doing work in the background. It answers a deceptively simple question: how long does it take to get from here to there?, for millions of pairs of places, across hundreds of regions. That lookup table is the Neighborhood Reachability Signal, and for years large parts of it were frozen in a snapshot of the world from 2018-2019. This is the story of how we rebuilt it, why a refresh substantial enough to be worth adopting was what finally moved Pricing to switch, the cleanly positive results that came out of that switch, and where we're taking it next, from one static file per region to time-aware travel times that change with the rhythm of the day. What is a Neighborhood Reachability Signal? A geohash is a compact way of carving the world into a grid of cells. At geohash-6 resolution, each cell is roughly the size of a few city blocks. Slice a region into geohash-6 cells and you get a clean, discrete coordinate system for "neighborhoods" that downstream systems can reason about. The Forecasting & Real-Time Optimization (FORTOP) team produces the Neighborhood Reachability Signals dataset, which consists of two companion files for each region: Neighborhood Reachability Matrix: the estimated travel time, in minutes, between the centers of pairs of geohash-6 cells. Think of it as a sparse origin-to-destination travel-time matrix for a region. Neighborhood Centers: the list of all geohashes that appear in the ETA files for that region, i.e. the "vocabulary" of cells that the marketplace is allowed to talk about. Both files are generated offline on a schedule by an Airflow DAG. They are static in the sense that they are precomputed and shipped, rather than queried live (which is exact ## Rerouting the Stream: How Lyft Moved to the Apache Flink Operator DevFeed: [Rerouting the Stream: How Lyft Moved to the Apache Flink Operator]() Original publisher: [Read original article]() Author: Maheep Myneni Published: 2026-08-31T19:08:16Z Content type: article Language: en Sources: [Lyft Engineering - Medium]() Topics: [Apache Iceberg](), [Streaming](), [Kubernetes](), [Open Source](), [autoscaling](), [Tooling](), [Architecture & Design]() Tags: [apache](), [apache-flink](), [autoscaling](), [data-platforms](), [infrastructure](), [kubernetes](), [lyft](), [open-source](), [production](), [streaming](), [streaming-data-processing](), [tooling]() ### AI overview Lyft describes its migration from an internally developed Flink Kubernetes operator to the open-source Apache Flink Kubernetes Operator. The move addressed maintenance burden, technical debt, feature gaps, outdated dependencies, and growing real-time streaming demands, while providing capabilities such as autoscaling, memory tuning, safer upgrades, and automatic rollbacks. ### Source excerpt Written by Maheep Myneni, Arda Kuyumcu, and Prem Santosh Udaya Shankar at Lyft. Why We Migrated: Technical Debt Meets Modern Streaming Demands Over the past several quarters, Lyft's Streaming Compute team retired our internally developed Flink Kubernetes operator and moved our entire streaming fleet onto the open-source Apache Flink Kubernetes operator. This post is about why we made the switch, how we pulled it off incrementally without disrupting users, and the follow-on work it took to actually get the benefits we were after. Back in 2020, when we first architected the Lyft Flink Kubernetes Operator, it was exactly what we needed. At that time, the open-source community hadn't yet built a dedicated control plane, so we built our own to manage all streaming applications on Kubernetes. It worked well for our initial workloads, but as our real-time data needs increased and our engineers' scope of ownership grew in both breadth and complexity, the cracks started to show. First came the maintenance burden. Our operator had become a relic of Lyft's early Kubernetes days, kept alive by a growing pile of custom code. Every Flink version upgrade meant carefully picking through layers of accumulated technical debt and hoping nothing broke on the way through. Second came the feature gap. Streaming tooling kept moving, and our engineers kept asking for capabilities that had become table stakes elsewhere, such as autoscaling to right-size jobs, automatic rollbacks on failed deploys, and an end to hand-tuning CPU and memory. Each request left us with two options, neither of which was ideal. We could explain why we couldn't support it yet, or spend weeks rebuilding something the open-source community had already shipped. Third was the dependency problem. We were pinned to outdated libraries. That doesn't break anything today, but it almost always creates new issues down the line. Security patches lagged, modern Kubernetes features stayed out of reach, and every quarter we waite ## Metric Semantic Layer: How Lyft Governs and Scales Key Data Definitions DevFeed: [Metric Semantic Layer: How Lyft Governs and Scales Key Data Definitions]() Original publisher: [Read original article]() Author: Iraklikhorguani Published: 2026-06-10T18:42:08Z Content type: article Language: en Sources: [Lyft Engineering - Medium]() Topics: [data]() Tags: [ai-and-mcp](), [data](), [data-governance](), [data-quality](), [knowledge-base](), [lyft](), [metric-standardization](), [metrics](), [python](), [semantic-layer](), [sql]() ### AI overview Lyft describes an internal Metric Semantic Layer that centralizes metric definitions, metadata, and SQL to maintain consistent terminology, governance, and downstream use. ### Source excerpt Written by Rohit Channe and Simran Mirchandani at Lyft. Motivation At Lyft, data isn't just a resource -- it's woven into everything we do. Metrics drive key forecasts, steer operational decisions, and put our boldest hypotheses to the test. But as Lyft scaled, products launched and evolved, and team members came and went, we found ourselves at risk of different teams using different definitions for a given metric. What did "Metric ABC" actually mean? The answer often depended on the context and application of the team you asked. The consequences were predictable. Without centralized version control or a shared standard, outdated metric definitions crept into decision-making. Our solution was to build an internal Metric Semantic Layer (MSL): a centralized repository that serves as a single, authoritative home for every metric's definition -- providing both a clear, plain-English description and the definitive SQL code. No more hunting across codebases or tribal knowledge -- just one place to store and access a standardized, agreed-upon definition. With MSL, we have a single source of truth -- consistent terminology and assumptions across every team, so everyone is genuinely speaking the same language. We achieve this through three key principles: Simplified onboarding and change management -- update a metric definition once, and the change automatically and frictionlessly flows through every downstream application that depends on it Intentional governance -- clarified ownership, defined scope, clear accountability for data quality, and a structure resilient enough to survive org changes, team rotations, and attrition Transparency and accessibility -- definitions are easy for both technical and non-technical users (and downstream applications) to find and integrate into day-to-day workflows Solution Taking the above principles into account, we implemented the Metrics Semantic Layer as a Python package: 1 -- Simplified onboarding and change management through flexible metric ## From Chaos to Clarity: How We Built a Unified, Self-Routing Support Ops Ticketing System at Lyft DevFeed: [From Chaos to Clarity: How We Built a Unified, Self-Routing Support Ops Ticketing System at Lyft]() Original publisher: [Read original article]() Author: Atulgupta Published: 2026-06-09T17:30:51Z Content type: article Language: en Sources: [Lyft Engineering - Medium]() Topics: [Routing (disambiguation)](), [dashboards]() Tags: [analytics](), [automation](), [dashboards](), [infrastructure](), [lyft](), [operations](), [operations-management](), [processes](), [routing](), [support](), [ticketing]() ### AI overview This article describes how Lyft Urban Solutions' Support Ops team transformed a fragmented Jira Help Center into a unified, automated, self-routing ticketing system. The redesign consolidated duplicate forms and categories, improved information capture, added labeling and routing logic, and introduced dashboards. The resulting system handles thousands of tickets annually, with one third routed automatically, reducing manual triage work. ### Source excerpt Written by Atul Gupta, Analytics Manager -- LUS Support Ops, Lyft At Lyft, getting operators and riders connected quickly and reliably depends on more than technology -- it depends on the teams working behind the scenes to keep that technology running smoothly. For the operators managing Lyft's fleet across markets, having fast, reliable access to support is what keeps bikes on the road, stations stocked, and issues resolved before they affect riders. Building the infrastructure that makes that support possible is what our team does; this is the story of how we built it. When I first joined Lyft Urban Solutions' (LUS) Support Ops team in 2020, ticketing processes for our operators were still being established. There was no reliable way to raise issues, track progress, or get routed to the right person. We had a Jira Help Center, but it had become increasingly difficult to navigate. What followed was a five-year journey of transforming that chaos into a streamlined, automated, self-routing system that now handles thousands of tickets per year, with one third of those routed automatically -- saving hours of manual triage work annually. The Problem: Organic Growth Gone Wrong On the surface, a Jira Help Center sounds like a reasonable solution. In practice, ours had become a maze. Here's what we were dealing with: Duplicate intake forms doing the same job under different names Redundant categories with no clear ownership Forms that didn't capture the right information upfront, forcing follow-up back-and-forth No auto-labeling, so tickets couldn't be searched or reported on No routing logic -- every ticket needed a human to read it and manually assign it No dashboards -- leadership had zero visibility into ticket volume or trends With this system, tickets would've taken the team 10-15 minutes to manually triage. It was time to redesign the system. Figure 1: Before and after: four fragmented portals consolidated into one unified Help Center with multiple categories across mult ## How We Built a Smarter Pickup Experience for Gated Communities DevFeed: [How We Built a Smarter Pickup Experience for Gated Communities]() Original publisher: [Read original article]() Author: winnieyan Published: 2026-04-23T19:16:44Z Content type: article Language: en Sources: [Lyft Engineering - Medium]() Topics: [App](), [data](), [Routing (disambiguation)]() Tags: [app](), [data](), [how-to](), [lyft](), [mapping](), [metrics](), [rideshare](), [routing]() ### AI overview Lyft's Mapping team describes how it identified and addressed pickup problems at gated communities. The article highlights two root causes: inflexible pickup-spot recommendations and the lack of a way to share gate-access instructions before a ride. The proposed solution is an end-to-end app experience involving map data, pickup recommendations, routing, and rider and driver workflows. ### Source excerpt If you live in a gated community, you've been there: You request a ride from your apartment complex, expect your driver to come to you as usual, and then -- your driver's car icon just stops right at the front gate. You watch helplessly as the ETA ticks up. A chat message comes in: "Hey, how do I get in?" You scramble to remember the gate code. They try it. It doesn't work. You end up meeting them awkwardly on the sidewalk outside while your coffee gets cold -- a pickup journey frustrating for both you and your driver. An example gated community in real life, Photo by Bingqian Li on Pexels It turns out you're not alone: Gated community pickups can make up 25-30% of Lyft rides in selected markets. For a long time, our app offered no special guidance in these situations. Riders would drop their pin inside the gates (fair enough -- that's where they are), while drivers would pull up to a locked entrance with no way in, leaving both parties to sort things out over chat. The result was predictable: more cancellations, longer waits, and a lot of unnecessary stress for our customers. The Lyft Mapping team decided it was time to fix this properly -- not with a band-aid, but a new end-to-end experience. Here's how we did it. What Was Actually Going Wrong? We looked through gated ride examples, zoomed into our metrics data, and found two root causes behind most of the friction. The first was an inflexible selection of pickup spots. Our app would suggest pickup spots near a rider's location -- which, for riders inside a gated community, often means inside the gate. But our data told a different story: many riders actually preferred meeting their driver right outside the gate, knowing their driver couldn't access the property. The app wasn't giving them that option clearly. The second was a communication black hole. Even riders who knew how to get their driver through the gate had no good way to pass along access instructions in advance. Instead, they'd wait until the driver was alr ## Predicting Rider Conversion in Sparse Data Environments with Bayesian Trees DevFeed: [Predicting Rider Conversion in Sparse Data Environments with Bayesian Trees]() Original publisher: [Read original article]() Author: Zammit Alban Published: 2026-03-30T14:43:41Z Content type: article Language: en Sources: [Lyft Engineering - Medium]() Topics: [AI, ML & Data Engineering](), [machine learning overfitting](), [Training AI Models](), [Language models]() Tags: [data](), [data-science](), [lyft](), [machine-learning](), [rider](), [ridesharing](), [statistics](), [transportation]() ### AI overview Lyft describes predicting whether a rider will request a ride after viewing a destination, price, and ETA. The article focuses on sparse, high-cardinality contextual data, where standard gradient-boosted-tree models can overfit, and introduces Bayesian trees as indicated by the title. ### Source excerpt At Lyft, understanding how riders go through our user experience is fundamental to operating a healthy marketplace. Specifically, it is important to have a robust model determining if a rider will actually request a ride after entering a destination and viewing a price and ETA. Accurately predicting this decision, that we call conversion, informs countless decisions across our platform. Whether it is to better balance supply and demand, improve user experiences, optimize recommendations and advertisement, understand long-term engagement, decide how to distribute coupons... rider conversion prediction is a central challenge for the Lyft business. However, predicting human behavior at scale is incredibly complex, and the exact same person might well open the app just to check current availability or actually to request a ride after viewing our prices. The contexts under which riders make their conversion decisions are extremely diverse and almost unique to each session. A user's intent changes based on where they are and where they want to go, what time it is, their previous interactions with the platform, current supply-demand market conditions, to cite a few. When we try to model this using standard machine learning approaches, we run into a significant challenge: data sparsity. The Challenge of High Cardinality and Sparsity To accurately predict conversion, we need to slice our data very thinly across many categorical features. Imagine trying to predict the conversion probability for a business traveler leaving the suburbs of Detroit at 4:00 AM on a Tuesday to catch their flight at the airport 30 minutes away. While Lyft has vast amounts of data overall, the amount of data available for that specific intersection of contexts often reveals to be very tiny. Maybe we only have ten examples in history. If we use standard techniques like Gradient Boosted Trees (e.g., LGBM, XGBoost), we encounter severe overfitting. A standard model looking at 10 examples in the training d ## Scaling Localization with AI at Lyft DevFeed: [Scaling Localization with AI at Lyft]() Original publisher: [Read original article]() Author: Stefan Zier Published: 2026-02-19T17:28:41Z Content type: article Language: en Sources: [Lyft Engineering - Medium]() Topics: [Localization (l10n)](), [Artificial Intelligence](), [Large Language Model](), [Latency](), [Prompt Engineering](), [Web]() Tags: [ai](), [architecture](), [artificial-intelligence](), [aws](), [code](), [compliance](), [distributed-systems](), [infrastructure](), [latency](), [llm](), [lyft](), [machine-learning](), [real-time](), [web]() ### AI overview Lyft re-architected its translation pipeline to combine AI with linguist oversight, context injection, evaluation, guardrails, and version-controlled prompts. The batch system reduces translation latency from days to minutes while supporting legal compliance and brand integrity across expanding markets. ### Source excerpt Written by Stefan Zier For years, Lyft's localization infrastructure relied exclusively on human translation. While this model usually ensured excellent quality, it was bound by multi-day turnarounds and costs that scaled linearly with every new language. For the few languages Lyft initially supported (Spanish, Portuguese, and French), these limits were acceptable. However, Lyft's expansion goals quickly outpaced what traditional workflows could support. Lyft's recent Québec launch required compliance with Bill 96 (legislation mandating French-first user experiences) which demanded faster turnaround than multi-day cycles allowed. Simultaneously, the Lyft Urban Solutions ("LUS": Bikes & Scooters) division sought to expand into European markets, requiring six new languages. The business need had changed as we now needed to move faster without sacrificing quality. This post explores how we re-architected Lyft's Translation Pipeline to leverage AI alongside linguist oversight and ultimately unlock new market launches. We will walk through context injection, decoupling content generation from evaluation, implementing guardrails, and treating prompts as version-controlled production code. The new pipeline reduces translation latency from days to minutes while maintaining the fidelity required for legal compliance and brand integrity. Note: We will walk through our batch translation pipeline -- used for 99% of app and web content -- which targets a 30-minute SLA for 95% of translations. We also support real-time translation (e.g., ride chat) which uses a different architecture.* How Translations Reach Hundreds of Services Before diving into the LLM pipeline, it helps to understand how translations flow through Lyft's infrastructure. This 2020 post explains the internationalization architecture initially built to move beyond one language/currency/country. Since then, the platform has grown to serve 11 locales across 150+ services. At its core, the pipeline does two things in ## Trusting the Untestable: Validation and Diagnostics for the Doubly Robust Models DevFeed: [Trusting the Untestable: Validation and Diagnostics for the Doubly Robust Models]() Original publisher: [Read original article]() Author: Shima Nassiri Published: 2026-02-12T17:07:13Z Content type: article Language: en Sources: [Lyft Engineering - Medium]() Topics: [Estimator](), [data](), [Monitoring]() Tags: [aipw](), [doubleml](), [evaluation](), [experiment](), [experimentation](), [lyft](), [measurement](), [models](), [quasi-experiment](), [rideshare](), [validation]() ### AI overview The article explains how Lyft uses quasi-experimental methods to measure causal effects when randomized A/B tests are impractical. It focuses on Augmented Inverse Propensity Weighting (AIPW), a doubly robust estimator that uses outcome and propensity-score models to estimate treatment effects from non-randomized data. ### Source excerpt written by Ross Chu and Shima Nassiri The Causal Frontier: Measurement Beyond Randomization The gold standard for determining the causal impact of a policy or product change at a company like Lyft is the A/B test (randomized experiment). By randomly assigning users to a treatment or control group, A/B tests inherently eliminate bias, providing clean estimates of the Average Treatment Effect (ATE). However, many critical business questions and large-scale initiatives simply cannot be randomized. This forces scientists to move past traditional experimentation and leverage quasi-experimental methods. We rely on non-randomized measurement in several key scenarios across Lyft: Partnerships and Policies: Assessing the incremental impact of a partnership (e.g., linking two company accounts) is often a non-randomized assignment. Since these collaborations require coordinated operational work across both companies and are typically announced or promoted broadly, this makes controlled randomization impractical. Long-Term Effect (LTE): Measuring effects that unfold over a long period, like the LTE of high prices on future rides, is typically handled by observational studies. Post-Launch Evaluation: Continuous monitoring of a policy after it has been fully rolled out requires a method that doesn't involve costly holdout groups or degradation tests. Biased Data: In cases where pre-existing experimental data is found to have an imbalance, a quasi-experimental approach can potentially leverage the biased data instead of requiring a costly rerun. Introducing Doubly Robust Models: Causal Inference Without Randomness To address these non-randomized measurement needs, Lyft relies on various quasi-experiment estimators. In this blog we specifically focus on using the Augmented Inverse Propensity Weighting (AIPW) model. This model was first established at Lyft to measure the impact of a negative user experience on future topline metrics like rides and bookings; AIPW is a form of doubly ## How Lyft powers batch and real-time analytics with ClickHouse Cloud DevFeed: [How Lyft powers batch and real-time analytics with ClickHouse Cloud]() Original publisher: [Read original article]() Author: ClickHouse Published: 2025-09-10T12:04:33Z Content type: article Language: en Sources: [ClickHouse Blog]() Topics: [data-processing](), [migration](), [Kafka](), [Amazon S3]() Tags: [analytics](), [batch](), [clickhouse](), [cloud](), [kafka](), [lyft](), [migration](), [real-time](), [s3]() ### AI overview Lyft describes moving from Apache Druid to ClickHouse Cloud for batch and real-time analytics. The article attributes the change to performance, simpler operations, lower costs, and scalability as data volumes and adoption grew. ### Source excerpt Lyft uses ClickHouse Cloud to power both batch and real-time analytics, handling 450+ TB of data daily, running hundreds of queries per second, and scaling efficiently beyond their legacy Druid system. ## Trino for large scale ETL at Lyft DevFeed: [Trino for large scale ETL at Lyft]() Original publisher: [Read original article]() Author: Charles Song, Ritesh Varyani, Brian Olsen Published: 2022-12-12T00:00:00Z Content type: article Language: en Sources: [Trino Blog]() Topics: [data](), [Amazon EC2]() Tags: [airflow](), [analytics](), [best-practices](), [data](), [java](), [lyft](), [scale](), [testing]() ### AI overview A Trino Summit recap describes Lyft's large-scale ETL deployment, including operational scale, cluster efficiency, rollback handling, workload separation, and query-testing practices. ### Source excerpt Buckle up, for the next post in the Trino Summit 2022 recap series. In this post, we're covering the talk given by Lyft engineers, Charles and Ritesh, on how they have not only scaled Trino as adoption grew, but with less nodes and more effective usage. They also started moving to utilizing Trino more for ETL rather than just interactive analytics. Get ready for a smooth ride as Lyft brings you large scale ETL with Trino. ## Top five reasons to attend Trino Summit 2022 DevFeed: [Top five reasons to attend Trino Summit 2022]() Original publisher: [Read original article]() Author: Brian Olsen Published: 2022-10-31T00:00:00Z Content type: article Language: en Sources: [Trino Blog]() Topics: [data](), [datasets]() Tags: [apple](), [architecture](), [blog](), [blog-post](), [conference](), [cost](), [data](), [free](), [lyft](), [production](), [scale](), [shopify](), [summit]() ### AI overview This blog post promotes Trino Summit 2022, a free in-person and virtual conference in San Francisco. It highlights industry speakers discussing Trino architectures, production use cases, scaling, and cost reduction; opportunities to meet the authors of Trino: The Definitive Guide; and Trino's ability to query heterogeneous datasets across multiple data sources. ### Source excerpt This blog post wraps up a series of previous posts teasing Trino Summit 2022. The conference is free and takes place in San Francisco, California on November 10th. Join us either in-person or virtually! Register now ## Trino Summit 2022: Sessions, speakers, and event details DevFeed: [Trino Summit 2022: Sessions, speakers, and event details]() Original publisher: [Read original article]() Author: Brian Olsen, Dain Sundstrom Published: 2022-09-22T00:00:00Z Content type: news Language: en Sources: [Trino Blog]() Topics: [data lake](), [SQL](), [Open Source](), [autoscaling]() Tags: [architectures](), [autoscaling](), [conference](), [data-lake](), [event](), [lyft](), [mpp](), [routing](), [summit]() ### AI overview This article announces Trino Summit 2022, a free hybrid conference taking place on November 10th, and previews selected sessions and speakers. Topics include Trino's open source project, query federation, large-scale ETL at Lyft, autoscaling, and fault-tolerant execution. ### Source excerpt Commander Bun Bun is back and this year we have an exciting lineup of speakers. Topics range from architectures like data mesh and data lakehouse, to running Trino at scale with fault-tolerant execution, and query federation. This conference is free and takes place on November 10th. The summit is a hybrid event for in-person and virtual attendance. Find out more details below! ## Using Amundsen to Support User Privacy via Metadata Collection at Square DevFeed: [Using Amundsen to Support User Privacy via Metadata Collection at Square]() Original publisher: [Read original article]() Author: Alyssa Ransbury Published: 2020-07-14T19:00:00Z Content type: article Language: en Sources: [Square Corner Blog RSS Feed]() Topics: [data](), [data-processing](), [graph-database](), [pii](), [BigQuery](), [MySQL](), [App]() Tags: [bigquery](), [collection](), [data](), [database](), [engineering](), [graph-database](), [lyft](), [mysql](), [netflix](), [pii](), [privacy]() ### AI overview Square describes using its own version of Amundsen to automate metadata collection and improve understanding of data stored, collected, and processed across many services while supporting user privacy. The system ingests schema information from Snowflake, BigQuery, and MySQL into a graph database, enabling search and richer column-level metadata such as PII semantic types and data storage security. ### Source excerpt More scalable, automated data insights while preserving users' privacy ## Automotive Privacy DevFeed: [Automotive Privacy]() Original publisher: [Read original article]() Author: Adam Published: 2018-07-09T00:00:00Z Content type: opinion Language: en Sources: [Shostack & Friends Blog]() Topics: [data](), [App]() Tags: [car](), [data](), [lyft](), [privacy](), [tracking]() ### AI overview This commentary examines automotive privacy concerns, including vehicle data collection and the difficulty of declining it. It discusses how cars and related technologies may associate trips with vehicle owners or passengers through license plates, toll beacons, sensors, maps, payment cards, and ride-booking apps. ### Source excerpt [no description provided]