The new, experimental Web Install API is now in Origin Trial in Microsoft Edge and Chrome. The API allows developers to programmatically trigger a PWA installation prompt from in-app user interactions. The API aims to simplify software discovery and distribution, particularly for users who are unaware of the install icon in the browser’s address bar or do not typically use app stores.

By Bruno Couriol

This is a submission for the 2026 WeCoded Challenge: Echoes of Experience

Student names and some details have been changed for privacy reasons. The stories are real and documented.

The kitchen where it all started

In 1999 I was working as a music specialist in Italian elementary and preschools — a position even more precarious and underpaid than a regular substitute teacher. I composed musical fairy tales for children using a keyboard, but it was limited and clumsy. I had never touched a computer in my life.

My mother, a furniture dealer, sold a kitchen to the owner of a computer shop. He never paid. To settle the debt, she took a PC instead. I asked for music composition software too. He gave me the programs — but without serial numbers. Useless. I looked up the price of legitimate licenses. Completely out of reach.

I didn’t even know what Reverse Engineering was. But driven by necessity, I started studying how software worked under the hood. By pure chance I stumbled onto the UIC — the Italian University of Hacking and Cracking — a buzzing forum full of brilliant people and hundreds of tutorials. I learned x86 assembly and how to use debuggers like SoftICE and OllyDbg to understand program logic. I just wanted to make the tools I needed to compose music for my kids work, but I ended up learning how a computer “thinks.”

Then something unexpected happened: after learning low-level languages, I became curious about high-level ones. I had always been good at drawing and loved animation — so I taught myself ActionScript.

That’s how a music teacher with zero computer science education became a programmer. Not through a bootcamp. Not through a degree. Through a kitchen debt and sheer stubbornness.

The girl who could write but couldn’t read

Just a few years later, in the early 2000s, I got a position as a special needs support teacher and met a student who would change the direction of my life.

She was 13 years old and had suffered significant brain damage in early childhood. She had graceful handwriting and good manual skills, but she could only copy. She had never learned to read — she didn’t know the name of a single letter. Every traditional method had failed. Teachers, specialists, therapists — everyone had tried. Nothing worked.

I knew she loved Disney’s Finding Nemo. So I built her a game — animations, handcrafted text-to-speech, I recorded my own voice to compose letters and words, all in ActionScript. I called it Nemo’s Letters.

For the first time, after years of failed attempts by everyone, that girl started decoding written words. Within a few months she learned the letters and the basic principles of assembling words.

That moment taught me something I’ve carried for twenty years: technology built around a real need — not a market trend, not a curriculum requirement, but one specific child’s specific struggle — can change a trajectory that everyone else had given up on.

Twenty years of starting over

After that first success, I kept building. And the technology kept dying under me.

ActionScript was deprecated. I migrated to Visual Basic. Then VB was replaced by VB.NET. Along the way I studied HTML and CSS. I built the first versions of MemoApp — a study tool — and Parla — a text-to-speech reader for students with reading difficulties.

Every time I mastered something, it became obsolete. Every tool I built became harder and harder to install. It was deeply frustrating — but I kept going. A small voice inside told me it was right not to give up, to try every possible path, and that my students needed these tools.

The real breakthrough came about four years ago, with the arrival of artificial intelligence.

At the time I was teaching in a challenging school. Large classes and countless difficult cases. As a special needs teacher I was a true support for the entire class: I regularly worked with groups of five, six, seven students, managing the curriculum across all subjects. My software was a winning piece of the puzzle, but installation problems on school and home computers were a constant nightmare.

With AI as a programming assistant, I migrated everything to JavaScript. It was similar enough to ActionScript to make the transition natural. And finally — everything worked. No installations. Everything in the browser. Accessible from any device. My students could finally use the same tools at home that we used in class.

Thanks to AI and the skills I had already built over the years, in four years I went from a handful of desktop applications to an ecosystem of roughly one hundred web apps.

What I built — and why nothing else worked

I need to be specific about the problem. As a special needs teacher in an Italian middle school, I follow students across every subject. In a single week, a class covers dozens of topics in math, history, geography, science, English, Italian — and all of that material has to pass through me. I need to take it, adapt it, simplify it and present it in a way that each student can actually learn from. I’m often asked to do this almost instantly.

Textbooks don’t work for these students. They require reading levels and attention spans that my students don’t have yet. Commercial educational apps look polished but miss the point: they don’t offer real verification tools for teachers, they don’t adapt to individual needs, they completely lack flexibility and they don’t integrate with each other. Concept maps from the web and simplified materials found online — praised by a certain school of educators — in my experience failed miserably and didn’t meet real needs.

But the real problem runs deeper. It’s not just about which material you give these students — assuming you can even find or generate the right one. The problem is that these kids haven’t developed a study method. They read poorly, look at the images, but don’t stop to understand. Everything goes in and out. They don’t even realize they haven’t learned or understood anything.

I realized early on that these students needed something to guide them step by step. Something that would stop them when they made mistakes and put them back on track. That would make them think. That would lead them to learn through a path built specifically for them. There was nothing on the market that came even close to these needs. And my hours were almost always too few — we wrote this in the IEPs (Individualized Education Plans) — and often these students had no guidance at home either.

So I built my own tools.

The backbone: the MemoApp suite

View high-resolution image for technical and pedagogical details

MemoApp, born about fifteen years ago and slowly refined and adapted, might look like just another quiz app, but it’s not. It has multiple modes of use, each with different purposes, goals and details to meet specific needs:

• Written quiz — the student answers primarily by writing. There’s also a mode for clicking options or making connections, but I’ve found that the writing mode — which forces repetition and active writing — produces the best results.

• Voice loop — pressing play makes the app repeat the quiz in a continuous loop. You can choose different voices for questions and answers — essential for language learning, where one voice is in Italian and the other in the target language. You can adjust the pause between question and answer because the goal is active learning: during the pause, the student tries to guess the answer mentally, then immediately hears it.

• Voice dialogue — the app asks questions and the student answers by speaking. It’s a real dialogue with the machine!

• Quick navigation — you browse through the quiz using arrow keys, for rapid review.

• Lesson mode — the teacher loads a quiz with images and uses it as the basis for a lesson (instead of a traditional presentation or Word document). Students see the question but not the answer: this pushes them to try to figure it out during the lesson, making learning active. At the end of the lesson, the teacher can scroll through the quiz asking surprise questions.

• Test simulation — the student answers all questions and only at the end does the app show how many were wrong. It helps understand how much has truly been absorbed and how much work remains — before the real test.

Flexible options — at any time you can shuffle or reverse the order of questions, swap questions and answers, delete specific questions — usually the ones already mastered.

And then there’s the heart of the system: intelligent error management with smart regression. If a student gets it wrong, they don’t start over and they don’t move on ignoring the error. The app shows the correct answer, asks them to retype it, and uses a system of progressive blocks. It records the questions with the most errors and then drills specifically on those. This is not a detail — it’s what makes the difference between a game and a learning tool.

In other words, MemoApp is a tool that safely guides the student through learning. It offers active learning, imposes structured study rhythms, checks results at every step, corrects mistakes, forces students to learn specific terminology, to order events and dates. Images further reinforce comprehension and retention.

CreaSchede — the instant generator

If MemoApp is the teaching tool you use in class, CreaSchede is its natural and indispensable complement. It’s the tool that teachers — or even students themselves — use to quickly and easily create MemoApp flashcards.

It works simply. The user describes what they want in a chat — for example “create a quiz on the main stages of Hitler’s rise to power, use a discursive text format, dedicate the first cards to terminology” — and can also attach images or documents. In two minutes they have 40 flashcards with real images from the web, saved to Notion with a unique ID. The teacher can quickly browse the cards, edit text and questions, scroll through image galleries to refine the visuals, paste images from the web, or provide images that the app will upload and insert into the quiz. When saving, the AI also offers a pre-filled form with the card name and details to make future searching and cataloguing easier.

The student enters that code in MemoApp — or searches by name — and starts studying. Images are automatically searched from seven different sources through micimici MCP, a server I built myself that queries Pexels, Pixabay, Unsplash, Wikimedia, Europeana, Bing and OpenClipart. Real images — not AI-generated. This matters: it’s scientifically confirmed that content is better absorbed when paired with images, and for education you need real photographs.

PrintMemoApp — because not everyone has a device

A concrete problem: not all students have a PC or tablet at home. PrintMemoApp takes MemoApp flashcards — currently over 600, all searchable in a database — and prints them in various modes: with or without images, with a cover image, with answers (becoming a study text), without answers (becoming a test or assignment), with answers in random order at the top (becoming a matching exercise). PrintMemoApp can also quickly transform quizzes into tests to administer on the spot. One piece of material, five different uses.

PageCraft — the page and game generator

The latest addition and perhaps the most versatile. PageCraft creates web pages, presentations, posters, printable documents and interactive educational games — Memory, board games, quizzes, runner games — from a simple chat description or directly from MemoApp flashcards. It searches real images automatically from all seven sources. It allows inline image editing, saving to Notion with three visibility levels (private, text-only, public) and a shared gallery where teachers can browse and reuse each other’s work. It runs on both Claude Artifacts and Gemini Canvas — same code, no vendor lock-in. The print system is meticulously designed, with zoom in and out options — because printing here isn’t optional, it’s a daily necessity.

The app can also load MemoApp flashcards directly from the database, so the same cards used for studying can be transformed into beautifully designed presentations, educational games, or printable worksheets.

Completely free. A Gamma alternative in an educational format, at zero cost.

The certification system — teachers need to verify

A fundamental aspect that’s often underestimated: if I assign work, I need to be able to verify it was done. I developed a JavaScript library shared across many of my apps. Through encryption, it records student activity — questions attempted, errors, time — and generates a link the student sends to the teacher. The teacher clicks and sees exactly what was done. This isn’t a technical detail: it’s what transforms an app from a toy into a professional teaching tool. Without certification, the teacher doesn’t know if the student studied, how much, or with what results. With certification, they can follow the student’s progress remotely.

And it’s all serverless, free and privacy-respecting.

Beyond the backbone: specialized suites

Geo-quiz — the difference between a game and a tool

Let me make a comparison that illustrates the point well. Seterra is a well-known platform for studying geography. Geo-quiz is visually similar — they probably even use the same library. But the difference is enormous.

With Seterra you pick a preset deck — “EU countries”, “Asian capitals” — and practice. But you can’t select just the 20 countries you need. If you get it wrong, you move on. The teacher has no idea whether the student studied. You can’t print anything for students without a device.

With Geo-quiz, the teacher asks the AI to generate a card set — “Middle Eastern countries” — and in a few minutes the set is ready. The student practices with the intelligent regression system: if they get it wrong, they don’t move on — they review, they repeat. There’s certification for the teacher. There’s a print system.

The result: Seterra is little more than a game. Geo-quiz is a professional suite.

A concrete example: Karim, learned 20 Asian and Middle Eastern countries in 20 minutes. On his own, without these tools, he would have managed 2 or 3 — and would have forgotten them, because at home he has no study support.

ImageMap — the same logic on any image

Similar to Geo-quiz but works with images instead of maps. The user uploads an image or provides a link, asks the AI to identify specific parts — European rivers, body parts, engine components — and within moments the card set is ready. Same certification and regression systems included.

Procedural apps — step-by-step guidance

Dozens of specific apps, mostly for mathematics: how to solve expressions, how to decompose a number into prime factors, how to measure an angle, proportions, integers, monomials, equations. Each app guides the student step by step through learning a procedure. It doesn’t just tell you whether the answer is right or wrong — it teaches you the process.

Write with AI — giving a voice to those who can’t express themselves

This app solves a problem that goes beyond school. Many students with difficulties can’t write complex texts. They write disconnected thoughts. They can’t build a narrative with a logical thread. And this isn’t just an academic problem — it’s existential: they can’t express themselves.

Even helping them is hard. Writing an essay takes hours. I often have to spend a long time talking with them, and sometimes to speed things up I almost end up writing it myself.

So I created this app. It takes the assignment as input — a text, an image, a document. Then it breaks it into points and proposes them to the student, who can modify them and discuss the structure with the AI. When satisfied, they click on each point and the app helps them develop it, always through dialogue. Copy-paste is disabled.

The app doesn’t write the essay for the student. It teaches the process: break your thoughts into points, develop them one at a time, connect them. Over time, students learn to do it without the app.

The results: the stories that matter

Amir — from two words to forty pages

Amir’s greatest difficulty was a communication impairment — expressing even a slightly complex concept was already a struggle. “Can I go to the bathroom” was fine. “If the weather were nice I’d take a walk in the park behind my house” was already beyond his reach. He wasn’t independent in reading or writing, his handwriting was illegible, likely dystorthographic. He could read just a few words at a time. His academic skills were almost nonexistent — roughly a second-grade level.

His mother had a similar condition, and was a single parent. No help at home. And I had only 9 hours per week to support him across all subjects.

The first year, without a PC, almost no progress. The second year his parents finally got him a device. The change was gradual but steady. MemoApp forced him to repeat concepts, to write — and slowly it unlocked him. At school I used the same flashcards he used at home to study. Same logical thread, same content. Little by little he relearned to read, write and study.

The pivotal moment came during a GLO meeting — the operational working group with educators and specialists. The educators from the afternoon center who worked with him said it clearly, and it was recorded in the official minutes:

“The student with and without the PC is completely different. They seem like almost two distinct people. Without it he’s not independent, he does nothing. With the program he studies on his own, he’s autonomous, he learns, he reviews.”

At the end of eighth grade, Amir presented a thesis of about forty pages on the Russian Revolution — from the Tsarist era to Stalin — with a deep dive on Rimsky-Korsakov, including his role as a naval officer and the curriculum of Russian naval academies. He spoke on his own for nearly an hour straight. He scored 10 out of 10 on his oral exam — and the commission applauded him. I can assure you that’s not standard practice, and it’s a rare event.

In sixth grade he couldn’t string two words together.

But the most important part came later. Toward the end of eighth grade, Amir started handling the family’s bureaucratic affairs. He told me: “My mother has trouble making herself understood, so I do it.” One day he arrived with a letter to write to the city council. I gave him a few guidelines. He did it on his own.

At 14 he had become the anchor of his family.

From the IEP signed by the neuropsychiatrists: “The student has made use of software created by the support teacher (MemoApp, Parla, PrintMemoApp), achieving greater independence in studying. Continuation is recommended. Performance is significantly lower without these methodologies.”

Karim — the soul that couldn’t find its way out

Karim arrived from Malawi to Italy in 2020, at age 8. In sixth grade he could barely do anything. He couldn’t express himself, couldn’t put two sentences together, couldn’t read 2-3 lines and understand the context.

Karim benefited from the complete suite — he had access to all the tools refined over two decades. The results were remarkable.

The 9 out of 10 on the Russian Revolution test happened like this: I sat in on a few hours of class, took notes, generated some flashcards. I spent about twenty minutes with him, showed him the cards to study, and told him he had to practice at home. He did all the work and studying on his own. He took the test when I wasn’t there — no help from me or anyone else. Nearly flawless. A well-deserved 9.

Today he follows most of the regular class curriculum without major simplifications — unthinkable just a year and a half ago. He himself admits that “the Karim from a year and a half ago was a different person.” From isolated to perfectly integrated in the class. His independence is growing, and with it his confidence.

But the most powerful proof isn’t a grade. It’s an essay.

Karim wrote this text using the “Write with AI” app, completely on his own, without my help or anyone else’s. We’re talking about a student who couldn’t sustain more than a couple of sentences with any logical thread.

The essay is titled “Friendship as a foundation for growing together” and it begins like this:

“My name is Karim and I come from Malawi. My arrival in Italy in 2020 when I was 8 years old was an un forgettable thing. The change from Malawi to Italy was hard also for me to know that there was an other world. When I left my friends I felt sad. The main difficulties I faced were that I didn’t know how to speak it. When I saw other children playing together I felt lonely and the wall surrounded the heart.”

There are errors. “Un forgettable” split in two. “An other world.” “The wall surrounded the heart” — which probably meant “my heart was surrounded by a wall.”

But those errors are proof it’s authentic. And that phrase — the wall surrounded the heart — is involuntary poetry. This is a boy who had a whole world inside him and didn’t have the tools to let it out.

This app gave him those tools. It didn’t write the essay for him. It taught him to break his thoughts into points, develop them, connect them. And what came out was his soul. His inner world. It opened him up to the world.

And the most touching truth is that the wall only began to crumble when he was able to name it and describe it.

That is the magic of this program.

The difficulties — or rather, the system

I’m 50 years old and after more than twenty years of service I’m still on temporary contracts. Recent school reforms have made my position even more fragile: every year the risk of not being reconfirmed grows, and with it the very real risk of being pushed out of the school system entirely. If that happened, the entire suite of tools I’ve built over twenty years would die with me.

I hold no formal IT qualifications — no degree, no master’s, not even the European Computer Driving Licence. I never pursued the latter because a course at that level wouldn’t have taught me anything beyond what I’d already learned through necessity and determination, while more advanced programs are too expensive and incompatible with the schedule of a substitute teacher. The paradox is bitter: official documents and reports written by neuropsychiatrists and multidisciplinary teams confirm that the tools I developed have been “essential” in some cases for students’ independence and academic success — yet the system continues to consider me “unqualified,” both as a teacher and in IT.

Meanwhile, schools are blocking AI even for educational purposes. Mine deactivated Gemini and prevented the installation of my Claude Artifact Unlock extension, which I need to run some applications like PageCraft. The distrust of technology — born from the bad practice of many students using AI to cheat — ends up penalizing those who use it virtuously. Some colleagues are curious, others skeptical. Despite visible results, the technology I created struggles to find its place.

I have never received a single cent for my work. But this has sparked a creativity that has become innovation in itself: I developed Claude Artifact Unlock knowing that AI was free inside artifacts; I created a cross-platform library to run apps on both Claude Artifacts and Gemini Canvas without changing code; I use Notion as a free database instead of renting servers; I host everything on Netlify and GitHub Pages; I created micimici MCP to source real images from seven different providers. Every economic constraint became a technical innovation. But it’s not right to go completely unrecognized.

This is precisely why I decided to enter this and other challenges. I desperately need to emerge from anonymity and be recognized for what I’ve built. Not for me — for the suite. Because if I don’t find visibility and support, all of this dies with me. And yet this path deserves to be recognized and strengthened. I still have dozens of ideas to realize: apps that don’t exist today and that could make a difference for thousands of students.

The message

I didn’t build apps that help students. I built apps that teach students to help themselves — and give them autonomy, growth and integration. The real kind. The authentic kind.

Too often my colleagues are forced to settle for levels of learning that barely scratch the surface. Inclusion is reduced to simply being in a classroom — but you can be in a classroom all day and still be alone. You can sit through hundreds of lessons and fill out tests without ever truly understanding what was taught.

I decided that wasn’t enough. That we had to go further. That integration didn’t mean just sitting next to your classmates, but interacting with them. Understanding class dynamics. Being able to express yourself. Following lessons. Thinking.

The goal was never the grade. It was always autonomy. Amir at 14 manages his family’s paperwork. Karim tells his soul’s story in an essay. They’re not just better students — they’re freer people.

Every app is born from a real need. There’s nothing on the market that does what’s needed? I build it. The technology gets deprecated? I start over. I have no money? I find free solutions. The school blocks the tools? I find alternative paths.

My technology journey — Assembly (1999) → ActionScript → Visual Basic → VB.NET → HTML/CSS/JavaScript with AI (2022) → today an ecosystem of ~100 web apps — is not a developer’s résumé. It’s the path of a teacher who refused to accept that her students couldn’t make it.

And the results speak for themselves.

Francesca Bertolini — music and special needs teacher, self-taught programmer, on temporary contracts for twenty years, convinced that the right technology can give every student the chance to walk on their own two feet.

System Design: Ride Booking (Uber / Ola)

🧠 Mental Model

Uber is two concurrent real-time systems: location tracking and driver matching. Every second, millions of drivers push their GPS coordinates. When a rider requests a trip, the system finds the closest available driver, atomically assigns them, and keeps both maps in sync — all under 300ms. The hardest problems are concurrency (preventing double-booking) and geospatial search at scale.

                ┌──────────────────────────────────────────────────────────────┐
                │                     FAST PATH                                 │
 ┌──────────┐  │  ┌───────────────┐  GEORADIUS   ┌──────────────┐             │
 │  Driver  │──►│  │ Location Svc  │ ───────────► │ Match Engine │ ──► Driver  │
 │  App     │  │  │ (Redis Geo)   │              │ (top K score)│    notified  │
 └──────────┘  │  └───────────────┘              └──────┬───────┘             │
  every 3-5s   │                                        │ SETNX (atomic lock) │
               └────────────────────────────────────────┼─────────────────────┘
                                                         │
               ┌─────────────────────────────────────────▼────────────────────┐
               │                    RELIABLE PATH                               │
               │  Trip event ──► Kafka ──► Trip DB (Postgres)                  │
               │  (start, end, fare, route) — durable, for billing & history   │
               └──────────────────────────────────────────────────────────────┘

⚡ Core Design Principle

[!IMPORTANT]
Driver location is fast path only. Location is overwritten every 3–5 seconds — only the latest value matters. Trip events are reliable path — they drive billing. Never conflate ephemeral real-time data (location) with durable transactional data (trip records).

[!NOTE]
Key Insight: Both paths run concurrently on every event. They are not sequential. The fast path can fail — the reliable path must not. Redis TTL is not a weakness; it is the correct primitive for data with a natural expiry.

1. Problem Statement & Scope

Design a ride-booking platform (Uber / Ola) supporting fare estimation, driver matching, real-time tracking, and payment — at millions of concurrent users and drivers.

In Scope: Fare estimation, ride booking, driver matching, real-time location tracking, trip start/end, ratings, payments.

Out of Scope: Driver onboarding, fleet management, surge zone boundary drawing, fraud detection internals.

2. Requirements

Functional

1. Rider gets fare estimate (per vehicle type) for a pickup + drop location
2. Rider books a ride; system matches a nearby available driver
3. Driver accepts or denies the ride request
4. Both rider and driver track each other in near real-time
5. Trip starts and ends; rider pays; both rate each other

Non-Functional

[!IMPORTANT]
CAP Theorem framing: This system intentionally makes different trade-offs per component. Rider-facing services (fare, history) prefer high availability. Driver assignment prefers strong consistency. You can and should say this explicitly in an interview — it shows CAP awareness at a component level.

3. Back-of-Envelope Estimations

Inputs:
  Total drivers online:       5 million
  Daily rides:                20 million
  Peak concurrent requests:   500,000
  Location update frequency:  1 per 3s (ON_TRIP), 1 per 5s (IDLE)

Location writes/sec:
  5M drivers × (1 update / 3s) = ~1.67M writes/sec → Redis must handle this

WebSocket connections (peak):
  5M drivers + ~2M active riders = ~7M persistent connections

Trip events/sec (Kafka):
  20M rides/day ÷ 86,400s = ~232 events/sec (well within Kafka capacity)

Storage:
  Trip record: ~1 KB × 20M rides/day = 20 GB/day (PostgreSQL)
  Location history (waypoints): ~500 GPS points × 16B × 20M trips = ~160 GB/day (cold storage)
  Driver metadata: 5M drivers × 1 KB = 5 GB (static, fits in memory)

Bandwidth:
  Location update frame (WebSocket): ~20 bytes
  Location update frame (HTTP polling): ~2 KB (headers + body)
  At 1.67M updates/sec: WebSocket = 33 MB/s vs HTTP = 3.3 GB/s → WebSocket wins by 100x

4. API Design

User-Facing Endpoints

Driver-Facing Endpoints

[!NOTE]
Key Insight: Driver location is a WebSocket, not REST. At 1.67M location updates/sec, HTTP overhead alone would cost 3.3 GB/sec in headers. WebSocket frames are ~20 bytes. The transport choice is arithmetic, not preference.

5. Architecture Diagrams

Simple High-Level Design

Evolved Design (with Kafka + Surge Pricing)

6. Deep Dives

6.1 Fare Estimation + Surge Pricing

Here is the problem: Fare calculation requires real-time distance, traffic, vehicle rates, and a surge multiplier. These come from different sources and must compose into a single response in < 500ms.

Flow — step by step:

Surge Pricing Design:

• Every fare request is logged to the Ride Request DB (analytics store, not transactional)
• Surge Calculator reads this DB, computes active_requests / idle_drivers per geohash cell
• If ratio > threshold (e.g., 1.5×): multiplier increases
• Ride Service caches the multiplier in Redis (surge:{geohash} TTL 60s) — re-read on each fare call
• Rider sees surge multiplier before confirming — informed consent

[!NOTE]
Key Insight: Surge pricing is a read-path concern only — it does not affect matching. The Surge Calculator is a separate service feeding data into Redis. The matching engine never touches it.

6.2 Location System

Location data is high-frequency and ephemeral. Storing it in a database creates write bottlenecks. We use Redis — not because it is fast, but because the data has no long-term value the moment the next update arrives.

Location systems trade accuracy for scalability. The frequency of updates is not a technical constraint — it is a deliberate cost/accuracy decision per driver state.

The scale problem: 1.67M driver location writes/sec, each needing sub-millisecond geospatial lookup for matching. No relational database survives this write rate.

Write Path vs Read Path

[!NOTE]
Key Insight: Write path and read path never conflict. Writes overwrite one sorted set entry (O(log N)). Reads scan a bounding box (O(N+log M)). No locking. No transactions. This is why Redis Geo handles 1.67M concurrent writes while serving sub-10ms matching queries.

Update Frequency by Driver State — Accuracy vs Cost Trade-off

The problem: More frequent updates = better map accuracy for the rider. But 5M drivers × 1 update/sec = 5M Redis writes/sec. Every frequency choice is a cost/accuracy trade-off.

The trade-off explicitly stated:

Chosen: State-adaptive frequency. IDLE drivers are not being watched by a rider — 5-second position accuracy is enough for the matching geo query. ON_TRIP drivers have a rider actively watching — 1-second is required for smooth map animation.

[!NOTE]
Key Insight: Update frequency is not a single tuning knob — it is a function of driver state. Sending 1-second updates from IDLE drivers wastes 60–70% of Redis write capacity for zero rider-visible benefit. The state machine (section 6.4) already knows each driver’s state — frequency is derived from it for free.

Batching: Location Service buffers 500ms of updates, pipeline-writes to Redis in one round-trip. Publishes to Kafka only for ON_TRIP drivers (rider needs real-time map). Reduces Redis write load 3–5× without increasing visible latency.

The Fan-Out Problem (ON_TRIP)

The driver’s WebSocket lands on Server A. The rider’s WebSocket is on Server B. A direct A → B push does not exist in a distributed system.

Solution: Kafka as the cross-server fan-out bus.

[!IMPORTANT]
Fan-out via Kafka is a correctness requirement, not a performance optimization. Without it, location updates only reach the rider if they happen to be on the same server — never guaranteed.

Stale Location Self-Healing

Driver phone disconnects → WebSocket closes → Location Svc detects
  → EXPIRE driver:state:{driver_id} 30
  → After 30s with no heartbeat: key expires → auto-removed from idle pool
  → No stale drivers offered to riders. No cron job needed.

6.3 Driver Matching

Driver matching is the core of the system — everything else (payments, UI, notifications) is secondary.

Here is the problem: When a rider requests a trip, find the best available nearby driver, offer them the ride, and assign atomically — without double-booking — in under 300ms.

The matching pipeline has 5 steps. They all run sequentially in < 300ms:

[1] Geo index search → [2] Eligibility filter → [3] ETA-based ranking
         → [4] Sequential dispatch + timeout → [5] Atomic state transition

Step 1: Geo Index Search (Geohash / H3)

Why a geo index? You cannot scan 5M driver rows in a DB on every ride request. A geo index converts 2D coordinates into a prefix-searchable key — nearby drivers share a key prefix.

Geohash (traditional approach): converts (lat, lng) → alphanumeric string. Cells are rectangular.

H3 (Uber’s actual approach): hexagonal cells. Every cell has exactly 6 equidistant neighbors — no edge/corner distortion like geohash rectangles. Uber open-sourced H3; this is what production systems use.

Pickup: (12.9716, 77.5946)
Geohash (6 chars): tdr1wc  → ~1.2km × 0.6km rectangle
H3 (resolution 8): 8828308281fffff → ~460m hexagon, 6 uniform neighbors

Redis command (geohash, in practice):
GEORADIUS drivers:idle:bangalore 77.5946 12.9716 3 km
         WITHDIST COUNT 100 ASC

Returns: [(driver_001, 0.3km), (driver_002, 0.7km), ...]

[!NOTE]
Key Insight: H3 hexagons have uniform neighbor distances — no corner distortion. This matters for ETA calculation: every cell edge is equidistant, so “expand to adjacent cell” expands coverage uniformly. Geohash rectangles have longer diagonals than edges, creating search radius inconsistencies.

Step 2: Eligibility Filter

From 100 GEORADIUS candidates, filter by:
  ✓ driver.state = IDLE            (not RESERVED or ON_TRIP)
  ✓ vehicle_type matches request
  ✓ acceptance_rate > 60%
  ✓ not blocked by this rider
  ✓ rating above minimum threshold
Remaining: ~10–20 eligible candidates → rank these

Step 3: ETA-Based Ranking (Not Distance)

Matching is not about finding the nearest driver. It is about finding the fastest pickup. ETA is the metric — not distance.

A driver 0.5km away in traffic has a worse ETA than one 1.2km away on an open road. Riders experience wait time, not map distance. Every system that ranks by distance is optimizing for the wrong thing.

For each eligible driver:
  1. Call routing engine (Google Maps / internal) with driver's current location → rider pickup
  2. Get eta_seconds (accounting for real-time traffic)
  3. Score:
       score = 0.50 × (1 / eta_seconds)       # ETA is primary signal
             + 0.25 × driver_rating            # quality
             + 0.15 × acceptance_rate          # reliability
             + 0.10 × (1 / trips_today)        # avoid fatigue

Top driver = lowest ETA + highest weighted score

[!IMPORTANT]
ETA vs distance — the critical distinction. Distance is a proxy for ETA, but a bad one in cities. Real systems call the routing engine for every candidate in the top-K set. This is expensive (~10ms per call), so the candidate set must be pre-filtered to ≤ 20 drivers before ETA calculation. That is exactly what steps 1 and 2 achieve.

Step 4: Sequential Dispatch with Timeout + Fallback Chain

Real systems offer drivers sequentially (normal conditions), not all at once. Here is the exact sequence:

1. Take top-ranked driver (lowest ETA score)
2. Attempt atomic state transition: IDLE → RESERVED (see Step 5)
   → FAIL: another request already reserved this driver → go to step 1 with next candidate
   → OK: proceed
3. Push ride offer to driver's WebSocket (15-second response window)
4. Driver responds:
   → ACCEPT: confirm ride, notify rider, lock state as RESERVED
   → DENY / no response in 15s: transition back RESERVED → IDLE, go to step 1 with next candidate
5. If all candidates in current radius exhausted: expand radius (see below)
6. If all 3 radius rounds exhausted: return "no driver found" to rider

Step 5: Atomic State Transition (The Consistency Mechanism)

Here is the key insight the feedback is pointing at: Real systems do not rely on a separate distributed lock. The state transition itself is the lock.

Atomic operation (Redis Lua script or MULTI/EXEC with WATCH):

WATCH driver:state:driver_001
  current = GET driver:state:driver_001
  IF current != "IDLE": DISCARD → another request got there first → skip this driver
  MULTI
    SET driver:state:driver_001 RESERVED EX 30
    ZREM drivers:idle:bangalore driver_001
  EXEC
    → OK:   state changed atomically. Driver removed from idle pool. Send offer.
    → FAIL: EXEC returned nil (someone else committed between WATCH and EXEC) → skip driver

The state machine is the lock. There is no separate lock:assignment key — the transition from IDLE → RESERVED is the mutual exclusion. If it fails, the driver is already taken. Move on.

[!IMPORTANT]
State machine replaces distributed locks. The atomic IDLE → RESERVED transition (WATCH/MULTI/EXEC) ensures a driver is either fully available or fully reserved — never both. No separate lock key. No TTL races. The state is the truth. This is why state machines at the Redis layer are the production pattern for preventing double-booking — not external lock services.

Radius Expansion

Round 1: 2km,  2-min timeout → quality match (close driver, good ETA)
Round 2: 3km,  2-min timeout → balance quality + availability
Round 3: 5km,  2-min timeout → availability over quality
Round 4:       → fail request → "no driver found"

6.4 Driver State Machine

Real systems do not prevent double-booking with a distributed lock. They prevent it by making the state transition itself atomic. The state machine is the lock.

Why this prevents double-booking — without a separate lock:

Each state maps to exactly one pool. A driver can only be in one pool at a time:

The atomic transition:

To reserve driver_001 for ride_A:

WATCH driver:state:driver_001
  current_state = GET driver:state:driver_001
  IF current_state != "IDLE":
    DISCARD          ← another request got here first → skip this driver
  MULTI
    SET driver:state:driver_001  RESERVED  EX 30
    ZREM drivers:idle:bangalore  driver_001
  EXEC
    → nil  (EXEC failed: state changed between WATCH and EXEC) → skip driver
    → OK   (atomic commit: state = RESERVED, removed from idle pool) → send offer

Two servers racing to reserve the same driver: only one EXEC succeeds. The other gets nil and moves to the next candidate. No lock key. No lock service. The state is the truth.

Crash recovery via TTL:

Driver app crashes mid-trip → WebSocket closes → heartbeat stops
  → TTL on driver:state:{driver_id} expires in 30s
  → Driver auto-transitions to OFFLINE
  → Removed from all pools automatically
  → No cleanup cron job needed

[!IMPORTANT]
The state machine replaces distributed locks. IDLE → RESERVED is the mutual exclusion. If two servers race, only one atomic WATCH/MULTI/EXEC commits. The other detects the conflict and skips. This is the production pattern — not a separate lock key, not ZooKeeper, not a DB row lock. The state machine IS the lock.

6.5 Fast Path vs Reliable Path

7. ⚖️ Key Trade-offs

[!TIP]
Every decision below follows: I chose X over Y because [reason at this scale]. The trade-off I accept is [downside], which is acceptable because [justification].

Trade-off 1: WebSocket vs HTTP Polling for Driver Location

Chosen: WebSocket.

I chose WebSocket over HTTP polling because at 5M drivers updating every 3 seconds, HTTP header overhead alone generates 3.3 GB/s of wasted bytes. WebSocket frames are ~20 bytes. The trade-off I accept is stateful sticky routing (driver must reconnect to the same server region), which is acceptable because the Location Service is partitioned by city and drivers rarely cross region boundaries mid-shift.

[!NOTE]
Key Insight: WebSocket vs HTTP is a math problem. 5M drivers × 1 update/3s × 2KB HTTP overhead = 3.3 GB/s in headers. WebSocket frames are ~20 bytes. The transport choice is arithmetic.

Trade-off 2: Redis Geo vs PostGIS for Geospatial Search

Chosen: Redis Geo for live driver positions. PostGIS for durable spatial data (surge zone boundaries, service area polygons).

I chose Redis Geo over PostGIS because driver position data is ephemeral — the previous coordinate has zero value the moment the next arrives. The trade-off I accept is that driver locations are lost on Redis failure, which is acceptable because drivers re-register within 15 seconds via their heartbeat WebSocket.

[!NOTE]
Key Insight: Use the right tool for the data’s lifetime. Ephemeral data belongs in Redis with TTL. Durable geospatial data belongs in PostGIS. Storing current driver locations in a DB is write amplification for data with a natural expiry.

Trade-off 3: Redis SETNX vs Database Pessimistic Lock for Driver Assignment

Here is the problem: two concurrent ride requests find the same top-scored driver. Both servers try to assign driver_001. Without a lock, one driver gets two rides simultaneously.

Chosen: Redis SETNX.

I chose Redis SETNX over a DB row lock because the same DB is already absorbing trip_start and trip_end writes from Kafka consumers. Adding 500K concurrent row locks on top of that creates contention that degrades trip write throughput. Redis is already in the stack for geospatial queries — SETNX adds zero new operational cost. The trade-off I accept is that a server crash mid-assignment leaves the lock held for up to 30s (TTL), which is acceptable because the matching engine simply picks the next candidate and retries.

[!NOTE]
Key Insight: DB SELECT FOR UPDATE is correct but expensive at scale — it serializes lock acquisition through disk I/O on the same DB under write pressure. Redis SETNX is a single in-memory atomic operation. When Redis is already in the stack, SETNX is the obvious choice: < 1ms vs 5–50ms, zero DB contention.

Trade-off 4: Sequential vs Parallel Driver Dispatch

Here is the problem: once we have a ranked list of candidates, do we offer the trip to one driver at a time (best driver first) or to all top-K simultaneously (fastest acceptance)?

Chosen: Dynamic — sequential in normal supply, parallel during surge.

We do not hard-code one strategy. In normal conditions, we prioritize quality: the best-ETA driver gets the first offer, other drivers are not disturbed. In surge, we prioritize speed: notify top-K simultaneously, first to accept wins. The supply/demand ratio determines the mode. The trade-off we accept is dispatch engine complexity, which is justified by measurable improvement in rider wait time at peak demand.

[!NOTE]
Key Insight: The optimal dispatch strategy is a function of supply/demand ratio, not a fixed architecture. Hard-coding either strategy means optimal in one condition and suboptimal in the other. The threshold is tunable per city.

Trade-off 5: Dynamic Radius Expansion vs Fixed Radius

Here is the problem: a small search radius gives high-quality matches but misses drivers in sparse areas. A large radius always finds drivers but returns poor ETAs.

Chosen: Dynamic expansion — 2km → 3km → 5km with 2-minute timeout per round.

We prioritize match quality first — start at 2km and expand only when necessary. A large fixed radius wastes ETA calculation on distant drivers and degrades rider experience with long pickup times. Expanding only on timeout means the system self-adapts to local supply conditions without manual tuning per city. The trade-off we accept is up to 4-minute matching latency in extreme sparse-supply cases, which is preferable to returning “no driver found” and forcing a re-request.

[!NOTE]
Key Insight: Fixed radius is a false economy. Starting small preserves ETA quality. Expanding only on timeout preserves match rate. The system adapts — we do not configure a radius per city.

Trade-off 6: At-Least-Once vs Exactly-Once for Trip Events

Chosen: At-least-once + idempotency key.

Each event: { event_id: UUID, ride_id, type, timestamp }
Consumer:   SET processed:{event_id} EX 86400 NX
  → OK:   process event
  → FAIL: duplicate — skip

I chose at-least-once + dedup over Kafka exactly-once because 2-phase commit adds broker-side overhead for a guarantee achievable more cheaply. The trade-off I accept is that idempotency logic must be implemented in every consumer — a developer discipline requirement, well-understood and low-risk.

[!NOTE]
Key Insight: Exactly-once delivery in Kafka requires 2-phase commit — expensive. At-least-once + idempotency key gives effectively-once delivery at near-zero cost. The Kafka queue is a correctness requirement (decoupling fast matching from reliable billing) — not just a performance optimization.

8. 🏁 Interview Summary

[!TIP]
When the interviewer says “walk me through your Uber design,” hit these points in order. Each is a decision with a clear WHY.

The 7 Decisions That Define This System

Fast Path vs Reliable Path

Fast Path   (latency):   Driver WS → Redis GEOADD → GEORADIUS → SETNX → WS push to driver
                         ON_TRIP: Redis → Kafka → WS push to rider map

Reliable Path (safety):  trip_start / trip_end → Kafka → PostgreSQL (billing, history)
                         Fare request → Ride Request DB → Surge Calculator

Location = fast path only (ephemeral, overwritten every 1-5s)
Trip record = reliable path (durable, drives billing and audit)

Key Insights Checklist

[!IMPORTANT]
These are the lines that make an interviewer lean forward. Know them cold.

• “Matching is not about finding the nearest driver — it is about finding the fastest pickup.” We rank by ETA, not distance. Distance is a proxy; ETA is the truth. Every system that ranks by distance is optimizing for the wrong metric.
• “Consistency in driver assignment is enforced through state transitions, not locks.” The atomic IDLE → RESERVED transition is the mutual exclusion. No separate lock service. No ZooKeeper. The state is the truth.
• “Location data is high-frequency and ephemeral — storing it in a DB creates write bottlenecks.” Redis holds only the current position. TTL self-evicts stale data. The previous coordinate has zero value the moment the next one arrives.
• “Sequential vs parallel dispatch is a supply/demand decision.” Hard-coding either strategy is wrong. Normal demand = sequential (quality). Surge = parallel (speed). The threshold is tunable per city.
• “The Kafka queue is a correctness requirement.” Decoupling fast matching (Redis, sub-100ms) from reliable billing (Kafka → DB) is what makes both guarantees achievable simultaneously.
• “CAP per component.” Rider-facing services are AP. Driver assignment is CP. The system is not uniformly one or the other — this is the right answer.

9. Frontend Notes

Frontend / Backend split for Uber: 50% / 50% — but the interview weight is heavily backend. Frontend deserves mention, not a full section.