# Building a Resilient Regional Bike-Sharing Network

A regional bike-sharing network behaves less like a single transit service and more like a distributed system. Our deployment spans three municipalities, 240 docking stations, and roughly 3,800 bicycles. Each city operates its own maintenance teams and pricing programs, while riders expect one account, consistent availability data, and seamless trips across municipal boundaries.

## Architecture at Regional Scale

Stations publish dock occupancy, battery health, and diagnostic events through cellular gateways every 30 seconds. These events enter a shared message broker and feed the trip service, maintenance dashboard, and public availability API. Because cellular coverage varies, gateways retain several hours of events locally and replay them after reconnecting; sequence numbers allow consumers to discard duplicates without losing legitimate state changes.

```yaml
station_gateway:
  publish_interval_seconds: 30
  offline_buffer_hours: 6
  retry_backoff_seconds: [5, 15, 60, 300]
```

## Keeping Availability Data Trustworthy

The rider application displays predicted availability rather than blindly exposing the latest station count. A station report becomes stale after two missed intervals, and the API reduces its confidence score accordingly. Trip starts and returns are also reconciled against dock telemetry, which catches stuck locks, bikes returned without a completed transaction, and gateways reporting an outdated inventory snapshot.

## Balancing Bikes Across Municipalities

Rebalancing combines historical demand, weather forecasts, commuter patterns, and current station capacity. Regional optimization matters because a bike borrowed near a suburban rail station may finish downtown in another municipality. Operational rules still preserve local service commitments: each city defines minimum coverage targets, while the optimizer recommends van routes that move bikes efficiently without draining neighboring districts.

## Reliability and Operations

We measure success through more than API uptime. Key indicators include unlock latency, failed return rate, stale-station percentage, and the number of stations that remain empty or full for over 20 minutes. During outages, stations can authorize short-lived offline rentals from cached credentials, and support staff can inspect a complete event timeline instead of piecing together logs from separate municipal systems.

## Lessons from the Rollout

The hardest integration work involved governance rather than telemetry. Municipal partners needed shared identifiers, common incident severities, and clear ownership when a cross-boundary trip failed. Establishing those contracts early made the technical platform simpler and gave riders what they actually notice: accurate maps, dependable locks, and a bike available when they need one.