Design EV charging station booking

Chargers connect to the backend, not the other way around, over WebSocket (OCPP 1.6J is still most common, 2.0.1 is growing), usually behind cellular modems with flaky connectivity. Run a fleet of stateful gateway nodes behind a TCP/TLS load balancer; each node holds ~10-20k sockets. The gateway only translates protocol: it validates messages, answers Heartbeat and BootNotification itself, publishes StatusNotification, StartTransaction, MeterValues and StopTransaction to Kafka keyed by charge_point_id (preserving per-charger order), and writes live status to Redis. It records which node owns which charger in Redis so the session service can route a RemoteStartTransaction to the right node, via an internal RPC or a per-node command queue. OCPP calls are request/response with a unique message ID; the gateway must correlate responses and time out. Since the charger retries messages it did not get a response for, every handler must be idempotent: a duplicate StartTransaction must not create a second session. Firmware differs across vendors, so keep vendor quirks in adapters, not in business services. Reconnect storms after a gateway deploy need slow draining and jittered reconnects.

A booking calendar alone gives wrong answers, because the physical connector can be occupied by a walk-in driver, a car that finished charging but was not moved, or be faulted. Combine both sources. Bookings live in Postgres with an exclusion constraint on (connector_id, slot) so overlapping bookings are impossible even under races; this is simpler and safer than application locks. Live state comes from the charger. Before a booked slot, send ReserveNow so the charger itself blocks other users; if the charger does not support reservations, stop selling walk-in sessions on that connector ~15 minutes before the booking, and cap walk-in sessions so they end in time. If the connector is faulted or occupied at slot start, the system automatically moves the booking to another free connector at the same station and notifies the driver, or refunds. Overstays are the real-world problem: apply an idle fee per minute after charging completes, notify the driver, and leave a buffer of ~10 minutes between bookings. Show the driver honest information: 'booked slots' and 'live status' separately.

Money must come from the meter, not from the app's timer. The OCPP StartTransaction carries meter_start (Wh) and StopTransaction carries meter_stop; energy = stop - start, priced by the station's tariff (per kWh, plus idle fees and GST). Chargers sometimes go offline mid-session and send StopTransaction hours later from their local queue; the session stays ACTIVE until then, and the bill is finalised when the stop arrives. If a charger never reports a stop, a reconciliation job uses the last MeterValues reading after a timeout and flags the session for review. Use a pre-authorisation at booking or start (card hold or wallet block) and capture the exact amount later, so a driver cannot run up an unpaid bill. All money movements are rows in a ledger with idempotency keys (session_id + type), so retries never double charge. Store raw meter samples for disputes, and use signed meter values where the hardware supports them (Eichrecht-style signing in Europe) for tamper evidence.

Drivers want one app for every network, but stations belong to many charge point operators (CPOs). Two integration types exist. For stations you operate or that connect directly to you, you speak OCPP. For stations on other networks, you speak OCPI (Open Charge Point Interface), which lets an e-mobility service provider (your app) and a CPO exchange locations, live status, tariffs, tokens, sessions and charge detail records (CDRs). Pull their station and status data into your station catalogue (and accept their push updates), and send start/stop commands through their OCPI command module. Their status freshness varies, so show a confidence or 'last updated' hint. Settlement uses CDRs: the CPO bills you per session and you bill the driver, so reconcile CDRs against your session records daily and alert on mismatches. This design keeps your booking and wallet logic the same regardless of whether the charger is yours or a partner's: a provider interface with OCPP and OCPI implementations.

Postgres EXCLUDE USING gist with a tstzrange rejects overlapping bookings atomically, survives crashes and needs no lock expiry logic. Redis locks per slot work only with fixed slot sizes and add failure modes. Booking QPS is low (single digits per second), so the database constraint is the right tool.

Fixed 30-minute slots are simple to display and reason about. Free ranges use chargers better but make the UI and fragmentation harder. Use flexible ranges in storage (tstzrange) and present 15-minute aligned choices in the UI.

Allowing only bookings wastes capacity when people do not book; walk-ins only frustrate travellers on highways. Mix both: cap bookings at e.g. 60% of connector-hours per station, keep the rest walk-in, and adjust per station by utilisation.

After a network blip, 60k chargers reconnect within seconds and each sends BootNotification and StatusNotification for every connector. Scale gateway nodes with headroom, answer boots quickly, rate limit status processing, and let the load balancer spread connections. Ask vendors to configure jittered reconnect intervals.

Demand concentrates on a few highway stations (e.g. Mumbai-Pune Expressway) on holiday weekends. Booking alone does not create capacity; show queue length and predicted wait, suggest the next station along the route, and enforce idle fees strictly.

Charging continues locally. The charger queues MeterValues and StopTransaction and sends them on reconnect. The app shows 'charger offline, session continues' with the last reading. Billing is finalised when the stop arrives or by reconciliation after a timeout.

The session is left in PENDING_START. If a StartTransaction arrives later, the session proceeds; if nothing arrives within ~60 s, mark it failed and release the pre-auth. Tell the driver to retry or use the charger's RFID/QR fallback.

Its chargers reconnect to other nodes within seconds; the routing table in Redis is updated on reconnect. In-flight commands fail and are retried by the session service with the same message idempotency.