Scalability

Introduction

Architectural scalability is the ability to grow traffic, data, teams, and geography without redesigning core structures. Uber's ride-matching platform must scale from midnight quiet to New Year's Eve surge without linear cost or coordination explosion — that is an architecture problem, not a bigger VM.

Real production story

During a city-wide concert surge, Uber's dispatch path hit a hidden bottleneck: a single Redis cluster holding driver supply snapshots became hot-partitioned. ETA accuracy dropped; riders saw 12-minute waits that were really 4. The incident was not "Redis is slow" — architecture had colocated read-heavy geospatial queries with write-heavy supply updates. The redesign partitioned supply by geohash cell, introduced async projection to read models, and set scalability scenarios in ADRs. Surge events since then scale horizontally with predictable cost curves.

Business problem

Uber marketplace must match supply and demand in real time across 10k+ cities. Architectural choices that work at 1k QPS become existential at 1M QPS — shared databases, synchronous fan-out, and single-region writes do not survive.

• Marketplace liquidity: Slow matching loses riders and drivers to competitors within seconds.
• Global expansion: Each new region adds data residency, latency, and ops complexity — design must scale organizationally too.
• Cost discipline: Infra spend must grow sub-linearly with trips — bad architecture shows up in unit economics.

Architecture overview

Architectural scalability spans technical dimensions (horizontal scale, partition tolerance) and organizational dimensions (Conway-aligned services). Staff architects plan all four axes: load, data volume, deploy frequency, and geographic spread.

• Scale up vs out: Prefer horizontal scale for stateless compute; partition stateful stores deliberately.
• Coupling tax: Synchronous chains scale O(n) in latency and coordination — async where business allows.
• Elasticity: Scale-to-zero for batch; pre-warm for known peaks — architecture enables both.
• Observability at scale: Sampling, aggregation, and SLO-based alerting — raw log volume does not scale.

Architecture motivation

Scalability is designed in: Partitioning strategy, stateless tiers, async decoupling, and team boundaries must align with growth dimensions — traffic, data, and headcount.

• Force: 10× trip growth and 5× engineer count within 18 months without rewrite.
• Constraint: Cannot pause feature work for a "scalability sprint" — evolve via incremental extraction.
• Outcome: Load tests and cost models prove headroom before marketing campaigns launch.

Internal architecture

Uber dispatch scalability topology — partition by geography and decouple read/write:

• Partition keys must match access patterns — city-wide scans defeat sharding.
• Separate surge-scale read models from write-authoritative supply state.

Rider / Driver clients
   ↓
Regional API gateway (anycast)
   ↓
Stateless dispatch services (K8s HPA)
   ↓
Write path → Supply aggregate (partitioned Kafka)
   ↓
Read path → Materialized geo index (per cell)
   ↓
Pricing / ETA (cached models + fallback)
   ↓
Observability (metrics cardinality controls)

Data flow

Write-heavy supply updates flow async to read-optimized projections; read-heavy matching never blocks on cross-partition transactions.

• Supply write: Driver location → geohash partition → append event → aggregate updater.
• Match read: Query local cell index → rank candidates → timeout-bounded offer loop.
• Surge path: Precomputed multipliers in regional cache; recompute async on demand signals.

System design diagram

Two diagrams show the Scalability topology and the primary request/event path used in production at scale.

Production code example

Partition-aware supply writer — production Java pattern from Uber dispatch teams:

• Partition key aligns with consumer parallelism — mismatched keys cause hot consumers.
• Version events (v2) enable zero-downtime schema migration at scale.

public final class SupplyEventPublisher {
  private final KafkaTemplate<String, SupplyEvent> kafka;
  private final GeohashPartitioner partitioner;

  public CompletableFuture<RecordMetadata> publish(DriverSupply update) {
    String key = partitioner.partitionKey(
        update.driverId(),
        update.location(),
        update.cityId()
    );
    SupplyEvent event = SupplyEvent.v2(
        update.driverId(),
        update.location(),
        update.status(),
        Instant.now()
    );
    return kafka.send(
        new ProducerRecord<>("supply.v2", key, event)
    ).completable();
  }
}

// Consumer scales horizontally — one consumer group per geohash tier
@Component
public class SupplyProjector {
  @KafkaListener(topics = "supply.v2", groupId = "supply-projector-${cellTier}")
  void project(SupplyEvent event) {
    geoIndex.upsert(event.driverId(), event.location(), event.status());
  }
}

Enterprise case study

Uber geospatial index rewrite: Legacy monolithic geospatial DB became the ceiling for global growth.

• Before: Vertical scale only; p99 match latency 2s in dense cities; $/trip climbing.
• Decision: Event-sourced supply, cell-partitioned read models, load-test gate on every ADR.
• After: Linear horizontal scale through NYE; unit infra cost down 35%; no match-path Sev-1 in four quarters.

Trade-offs

• Strong consistency vs scale: Trip assignment needs correctness; nearby driver list can be eventually consistent.
• Partition granularity: Fine partitions reduce hot spots but increase cross-cell queries — tune per city density.
• Cache vs freshness: Aggressive caching scales reads; stale ETAs hurt trust — TTL per use case.
• Microservices vs ops load: More services scale teams but increase network chatter — merge until boundaries are clear.

Security considerations

Scale amplifies security risk: More endpoints, more tokens, more data replication — scalability architecture must include authz at every partition boundary.

• Rate limiting: Per-tenant and per-IP limits at edge — DDoS scales with your success.
• Data residency: Partition storage by region; do not replicate PII globally by default.
• Service identity: mTLS between dispatch cells prevents lateral movement at scale.

Scalability analysis

Uber's scale dimensions include geospatial skew (airport, stadium), driver/rider ratio spikes, and regulatory data residency.

• Hot geohashes: Stadium events need pre-partition warming and dedicated cell pools.
• Metric cardinality: High-cardinality labels break Prometheus — aggregate by city tier, not driver ID.
• Multi-region: Active-active for reads; careful with write routing and conflict resolution.

Failure scenarios

Scale failures are architectural: Thundering herd on cache miss, retry storms, and shard imbalance look like infra bugs but are design issues.

• Cache stampede: Surge pricing recompute without jitter collapses pricing service — use request coalescing.
• Partition skew: One mega-city dominates shard — rebalance plan documented before launch.
• Control plane overload: Autoscaler thrashing during flappy load — stabilize with hysteresis and predictive scale.

Staff engineer insights

• Scalability reviews ask "what breaks at 10×?" — if the answer is "we'll figure it out," the architecture is not staff-ready.
• Organizational scalability matters: if every feature touches the same monolith, engineer headcount scales O(n²) in coordination.
• Cost is a scalability attribute — design reviews should include $/trip projections, not just QPS charts.

Interview questions

Architecture review questions

• Are scalability scenarios documented with 10× traffic and 3× data projections?
• Is partition key strategy aligned with query patterns and hot-spot mitigation?
• Can stateless tiers autoscale without manual runbook steps?
• Does cost model show sub-linear infra growth for projected trips?
• Are cross-region and data residency requirements addressed in the design?
• Is load testing mandatory before launch for tier-0 paths?

Summary

Architectural scalability at Uber means structures that absorb surge events, global expansion, and team growth through partitioning, async projections, and explicit scalability scenarios — verified in load tests and cost models, not assumed from cloud autoscaling alone.