DEV Community: Ayesha Iftikhar

How Uber Computes Estimated Time of Arrival (ETA)

Ayesha Iftikhar — Sat, 26 Sep 2026 17:05:43 +0000

Short answer: how does Uber compute ETA?
Uber snaps noisy GPS pings to the road network (map matching), finds candidate routes on a road graph, and predicts travel time for each road segment with machine-learning models fed by real-time traffic. It then sums and corrects the route estimate, models its uncertainty, and keeps refreshing the Uber ETA as the trip progresses.

For a ride-hailing platform like Uber, Estimated Time of Arrival (ETA) is not a cosmetic feature. It is a core real-time decisioning system that directly influences conversion, matching quality, pricing behavior, and user trust.

An inaccurate ETA increases cancellations, reduces marketplace liquidity, and weakens reliability perception. At scale, even small percentage errors can have measurable business impact.

1. Problem Definition

Uber must estimate two different time horizons:

Pickup ETA: Time for the driver to reach the rider
Trip ETA: Time from pickup to destination

This happens under hard constraints: real-time computation, global traffic variability, sparse-data regions, continuous driver movement, and noisy GPS streams.

2. System Architecture Overview

Uber's ETA stack is a multi-layer system where each layer solves a specific sub-problem:

Data ingestion for live GPS and traffic signals
Map matching to align noisy locations to roads
Routing to generate path candidates
Feature engineering for temporal and contextual signals
Machine learning for segment-level travel-time prediction
Online serving for low-latency ETA responses

3. Data Inputs that Drive Accuracy

ETA quality depends on combining real-time, historical, and context-rich features:

**Real-time: **driver GPS, speed vectors, congestion, live traffic feeds
Historical: time-of-day trends, weekday patterns, road speed distributions, weather and holiday effects
Contextual: city density, special events, roadwork, and construction zones

4. Map Matching and Graph Routing

Raw GPS is inherently noisy. Before route estimation, positions are snapped to likely road segments using probabilistic map-matching methods, often including Hidden Markov Model-style inference.

The road network is then represented as a weighted directed graph where intersections are nodes and road segments are edges. Edge weights represent traversal time, not just distance.

Routing engines apply optimized shortest-path methods such as Dijkstra, A*, and contraction hierarchies with real-time weight updates from live traffic.

5. Travel Time Estimation via Machine Learning

Uber does not rely purely on static shortest-path output. It predicts travel time at the road-segment level using machine learning.

Current speed and congestion
Historical average segment speed
Time bucket and day effects
Weather condition
Road type and intersection complexity

Model evolution typically progresses from linear models to gradient boosting and then to deep temporal architectures that better capture time-series traffic dynamics.

6. Pickup ETA Computation Logic

Pickup ETA is often harder than trip ETA because drivers may be moving, finishing another ride, or deviating in dense traffic.

Pickup ETA ≈ Remaining current segment time + optimal route time + intersection delay adjustments.

The system also computes uncertainty margins so user-facing predictions are robust under variance.

7. Real-Time Recalculation

ETA is continuously refreshed every few seconds using:

Live GPS deltas
Congestion updates
Route deviation detection
Dynamic re-routing logic If traffic spikes or route conditions shift, ETA is recomputed immediately.

8. Offline Training and Online Serving

The architecture is split into two stages for scale and latency:

Offline: train on billions of trips, build region-specific models, retrain continuously
Online: low-latency inference with feature store lookups, caching, and approximate serving optimizations Production latency targets are strict, commonly sub-100 ms for inference pathways.

9. Uncertainty and Confidence Modeling

ETA systems must model variance explicitly rather than output a single deterministic number.

Confidence intervals
Percentile ETAs (for example P50 and P90)
Error calibration curves
This enables messaging like "Arriving in 5–7 minutes" and improves perceived reliability.

10. Global Scaling Challenges

City diversity: each city has distinct traffic behavior requiring regionalized models
Sparse regions: cold-start geographies rely more on map priors, traffic APIs, and transfer learning
GPS distortion: urban canyons require smoothing with Kalman filters and trajectory correction

11. Continuous Improvement Loop

Uber improves ETA with a feedback cycle that combines A/B testing, prediction error pipelines, cancellation correlation analysis, and operational feedback from drivers and riders.

When ETA error patterns correlate with cancellation spikes, retraining and feature adjustments are prioritized.

12. Business Impact

Accurate ETA improves ride acceptance, reduces cancellations, raises driver utilization, and increases marketplace efficiency. Even small gains in ETA precision create significant revenue and trust impact at global scale.

13. Lessons for Engineers

Do not rely only on shortest-path algorithms
Predict at segment level instead of full-route level
Separate heavy offline ML from low-latency online serving
Model uncertainty explicitly, not optionally
Retrain continuously as traffic behavior shifts

Key Takeaway

Uber's ETA engine is far more than distance divided by speed. It is a distributed, real-time intelligence system combining graph theory, probabilistic modeling, deep learning, and infrastructure engineering under strict latency and reliability constraints.

How I Built a Local-First Journaling App with Flutter, Drift and Firebase

Ayesha Iftikhar — Wed, 23 Sep 2026 12:33:13 +0000

I build Mindleau, a free brain-dump journal and mood tracker for iOS and Android. From day one, it had one hard requirement: you should be able to open the app and start writing without creating an account or having an internet connection.

Journal entries are some of the most private things people type, and the moment someone needs to empty their head is probably the worst possible time to show them a sign-up form.

That requirement shaped the whole architecture. Here's how it's built, including the tradeoffs.

The stack

Flutter for iOS and Android from one codebase
Drift (typed SQLite) as the source of truth
Firebase Auth + Cloud Firestore for optional background sync
provider + ChangeNotifier / ValueNotifier for state. No Riverpod, no Bloc. The app is small enough that it didn't need them.

The central rule: the UI never talks to Firestore. Every screen reads and writes through a single repository, and the repository only writes to SQLite. Sync happens afterwards, in the background.

Screens ──► SanctuaryRepository ──► Drift (SQLite)   ◄── source of truth
                      │
                      └──(background)──► SyncService ──► Firestore

1. Every syncable table carries its own sync state

Instead of a separate outbox table, each syncable row records whether it has been pushed:

class BrainDumpRows extends Table {
  IntColumn get id => integer().autoIncrement()();
  TextColumn get remoteId => text().nullable()();
  TextColumn get content => text()();
  DateTimeColumn get createdAt => dateTime()();
  DateTimeColumn get updatedAt => dateTime().clientDefault(DateTime.now)();
  DateTimeColumn get deletedAt => dateTime().nullable()();   // soft delete
  TextColumn get mood => text()();
  TextColumn get focusTagsCsv => text()();
  TextColumn get syncStatus =>
      text().withDefault(const Constant('synced'))();       // pending_create | pending_update | synced
  DateTimeColumn get lastSyncedAt => dateTime().nullable()();
}

Four columns carry the sync logic:

remoteId maps the local autoincrement ID to the Firestore document ID.
updatedAt drives conflict resolution (more on that below).
deletedAt is a tombstone. Hard-deleting a row locally would leave nothing to tell the server it's gone.
syncStatus makes "what still needs pushing?" a single indexed query.

2. Writes are local and synchronous; sync is fire-and-forget

Saving a brain dump is a plain SQLite insert, marked as pending, followed by a sync attempt the UI doesn't wait for:

Future<int> saveBrainDump({
  required String content,
  required String mood,
  required List<String> focusTags,
}) async {
  final now = DateTime.now();
  final id = await _database.into(_database.brainDumpRows).insert(
        BrainDumpRowsCompanion.insert(
          content: content,
          createdAt: now,
          updatedAt: Value(now),
          mood: mood,
          focusTagsCsv: _encodeList(focusTags),
          syncStatus: const Value('pending_create'),
        ),
      );
  unawaited(syncNow()); // never blocks the save
  return id;
}

The user sees their entry immediately. Whether sync then succeeds, fails, or can't run because there's no signal changes nothing on screen.

3. Sync is pull-then-push, last-write-wins

syncNow() runs the same steps every time:

Future<void> syncNow() async {
  if (!await _canAttemptCloudSync()) return;
  try {
    if (!await service.ensureSignedIn()) return;
    await _pullRemoteChanges(service);
    await _pushPreferences(service);
    await _pushBrainDumps(service);
    await _pushMoodCheckIns(service);
    await _pushLearnProgress(service);
  } catch (error, stackTrace) {
    log('Sync failed', error: error, stackTrace: stackTrace);
  }
}

Pulling first means remote changes (from another device) are merged before local pending rows are pushed. The merge rule is plain last-write-wins on updatedAt:

final existing = await (_database.select(_database.brainDumpRows)
      ..where((t) => t.remoteId.equals(remoteId)))
    .getSingleOrNull();

// Local copy is newer: keep it; it'll be pushed next.
if (existing != null && existing.updatedAt.isAfter(remoteUpdatedAt)) return;

Tradeoff: LWW can lose an edit if the same entry is changed on two offline devices. For a personal journal, where one person is almost always on one device at a time, that's acceptable. A CRDT would add a lot of complexity to prevent a conflict that almost never happens here.

4. Anonymous auth first, email later

"No account required" and "sync across devices" pull in opposite directions. Firebase anonymous auth solves it:

On first sync, the app signs in anonymously. The user never sees a form, but their data has a stable users/{uid} path in Firestore.
If they later add an email, the anonymous account is linked to an email-link credential, so the same UID and data carry over.
On a new phone, the email link restores that account.

If anonymous auth is disabled or unreachable, ensureSignedIn() returns false and sync is skipped. The app keeps working from SQLite either way.

5. Bound every network call

This bug took me a while to understand. Firestore and Firebase Auth calls have no built-in timeout. On a flaky connection that isn't fully offline, an await can hang forever, leaving a spinner with no way out. Every network call now goes through one wrapper:

const _networkTimeout = Duration(seconds: 15);

Future<T> _withTimeout<T>(Future<T> action) => action.timeout(
      _networkTimeout,
      onTimeout: () => throw const NetworkTimeoutException(),
    );

Because the UI never awaits sync, a timeout just means "try again later". When connectivity comes back, a listener calls syncNow() and every row that isn't synced goes up.

6. Migrations are part of the product

Moving from "local only" to "local-first with sync" meant adding sync columns to tables that already held real user data. Drift's MigrationStrategy makes this explicit and versioned:

@override
int get schemaVersion => 5;

@override
MigrationStrategy get migration => MigrationStrategy(
      onUpgrade: (m, from, to) async {
        if (from < 2) {
          await m.addColumn(brainDumpRows, brainDumpRows.remoteId);
          await m.addColumn(brainDumpRows, brainDumpRows.syncStatus);
          // ...
        }
        if (from < 5) {
          await m.createTable(stillnessSessionRows);
        }
      },
    );

One lesson: SQLite won't add a NOT NULL column without a SQL-level default, and Drift's clientDefault only exists in Dart. So updated_at needed a raw ALTER TABLE ... ADD COLUMN updated_at INTEGER NOT NULL DEFAULT 0 for the rows already on users' phones.

7. Not everything has to sync

Guided stillness sessions (a timer-based breathing pause) are local-only on purpose. They only feed streaks and the 30-day heatmap, so syncing them wasn't worth the extra code and the extra data leaving the device. Deciding what not to sync is part of the privacy design.

What I'd do differently

Start with the sync columns. Adding them in migration v2 was avoidable.
Store tags as a JSON column, not CSV. CSV was quick at first and has been awkward to work with since.
Write the timeout wrapper on day one. Hanging awaits are the worst kind of offline bug because they only show up on bad networks, never at your desk.

Takeaways

If you're building anything personal (journals, habit trackers, notes), local-first is less work than it sounds:

Make SQLite the source of truth.
Put a syncStatus and updatedAt on every row.
Never let the UI wait for the network.
Use anonymous auth so "no account" and "sync" can coexist.

You can see the result in Mindleau. It's free on iOS and Android, and you can start writing without signing up. Questions about the sync design are welcome in the comments.

How to Generate a Secure JWT Secret Key in Node.js

Ayesha Iftikhar — Wed, 13 Aug 2025 10:35:52 +0000

When working with JWT (JSON Web Tokens) in a Node.js application, your secret key plays a critical role in signing and verifying tokens.

A weak or predictable key can compromise your application’s security, so it’s best to generate it randomly.

Here’s how you can easily create a strong JWT secret key using Node.js:

Add Script to package.json

Open your package.json and inside the "scripts" section, add:

"scripts": {
  "jwt-key": "node -e \"console.log(require('crypto').randomBytes(32).toString('hex'))\""
}

Run the script
In your terminal run:

npm run jwt-key

You will get:

a47f7c20e4f9a87c6d0af6e6c8c4bc25d2a8e7c4a9f5c30f72db7d9a48f1c3d2

Copy that string into your .env file.

If you use this often, you can even combine it with a direct write to .env so it replaces the JWT secret automatically:

"scripts": {
  "jwt-key": "echo JWT_SECRET=$(node -e \"console.log(require('crypto').randomBytes(32).toString('hex'))\") > .env"
}

This will overwrite .env with the new secret each time.