# Building a Regional Bike-Sharing Network That Survives Peak Demand

A regional bike-sharing network looks simple from the curb: unlock a bike, ride it, and return it near a destination. Behind that interaction is a distributed system spanning several municipalities, thousands of bicycles, docking stations, mobile clients, payment providers, and maintenance teams. Our network serves dense downtown corridors, suburban rail hubs, and seasonal waterfront routes, so demand patterns vary sharply by location and time of day.

## Designing for Intermittent Connectivity

Each station controller maintains a local cache of bike and dock states because cellular connectivity is not guaranteed. Unlock requests are validated centrally when possible, but stations can issue short-lived offline permits for recently authenticated members. Events are appended to a local journal and synchronized once connectivity returns; the backend treats every event as idempotent and uses station-generated sequence numbers to detect gaps.

```yaml
station_sync:
  interval_seconds: 15
  offline_permit_ttl_minutes: 10
  retry_backoff_seconds: [5, 15, 60, 300]
```

## Keeping Inventory Useful

Availability is more valuable than raw fleet size. A station with twenty bikes and no empty docks is effectively unavailable to arriving riders, while an empty commuter station fails departing riders. We combine historical trip data, weather forecasts, transit schedules, and live inventory to produce 30-minute demand forecasts. Dispatchers receive suggested rebalancing routes, but retain control when road closures, public events, or vehicle capacity make the optimized plan impractical.

## Maintaining Consistent Trip State

Trips cross municipal boundaries, which complicates pricing, taxation, and customer support. The trip service records immutable start and end events, then applies regional pricing rules asynchronously. If a dock reports a return after the mobile app times out, reconciliation closes the trip without charging the rider for the delay. Support staff can inspect the event timeline, but corrections are stored as compensating entries rather than edits to the original record.

## Operating the Network

We monitor unlock latency, station synchronization lag, failed returns, battery levels, and the percentage of stations in a balanced state. Alerts are grouped geographically so a carrier outage affecting forty stations creates one incident instead of forty pages. The most useful reliability metric is successful trip completion: a fast API means little if riders cannot find a bike, open the lock, or end the trip cleanly.