Design a Tesla Supercharger service

Problem Statement

Design a high-speed electric vehicle charging network that enables seamless "plug and charge" functionality. When a driver connects their vehicle to a charging stall, the system should automatically identify the car, authenticate the owner, begin delivering power, stream live session metrics to the vehicle dashboard and mobile app, and settle payment to the account on file -- all without requiring any manual interaction with apps, payment cards, or station interfaces.

Your system spans edge hardware (chargers and site controllers), cloud services (authentication, billing, telemetry), and client surfaces (in-vehicle UI, mobile app). It must handle network partitions gracefully because charging stations in remote corridors may lose internet connectivity yet still need to serve vehicles. Revenue integrity is paramount: every kilowatt-hour delivered must be metered and billed exactly once, even when components fail mid-session or connectivity drops for hours.

Key Requirements

Functional

• Plug-and-charge authentication -- the vehicle and charger perform mutual cryptographic authentication within seconds of cable connection, with no driver interaction required
• Real-time session telemetry -- stream power rate, energy delivered, estimated cost, and time remaining to the vehicle dashboard and mobile app with sub-10-second freshness
• Automated billing -- charge the registered payment method after session completion with itemized receipts, retry logic for declined payments, and user notifications
• Station discovery -- allow drivers to view stall availability, connector compatibility, current pricing, and estimated wait times before arriving
• Dynamic power allocation -- distribute finite site power across all active stalls fairly, adjusting per-vehicle rates as vehicles arrive and depart

Non-Functional

• Scalability -- support 50,000-plus charging stations globally with 100,000-plus concurrent sessions during peak travel periods
• Reliability -- maintain 99.9 percent uptime for the critical authentication and charging initiation path, with offline operation capability at stations for up to 24 hours
• Latency -- complete vehicle authentication and power delivery initiation within 3 seconds of plug-in; reflect power rate changes in the vehicle display within 5 seconds
• Consistency -- guarantee exactly-once billing semantics; accept eventual consistency for station availability aggregates and historical analytics

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Offline Operation and Edge Autonomy

Charging stations must continue serving vehicles when cloud connectivity fails. A design that requires online access to start a session will strand drivers during backhaul outages. Interviewers want to see how you balance local autonomy with centralized control and post-reconnection reconciliation.

Hints to consider:

• Cache authorized vehicle allowlists, pricing tables, and configuration at each site controller, with staleness bounds and periodic refresh
• Implement local risk management that allows offline sessions up to a monetary or energy cap before requiring cloud confirmation
• Design a durable local event log that buffers session starts, periodic meter readings, and completions until connectivity restores
• Build reconciliation workflows that replay buffered events to the cloud billing system and detect conflicts such as duplicate or missing data

2. Authentication and Fraud Prevention

Simple identifiers like VIN or MAC address are easily spoofed. Interviewers expect hardware-backed cryptographic identity with revocation support and short-lived session tokens.

Hints to consider:

• Use certificate-based mutual TLS with hardware security modules in both the vehicle and the charger to establish identity
• Issue short-lived session tokens after the initial PKI handshake to avoid repeated expensive cryptographic operations during the session
• Build a credential revocation mechanism that propagates to edge stations even during network partitions
• Consider a guest charging flow for vehicles not enrolled in the network, requiring payment card interaction at the station

3. Charging Session State Machine

A session spans authentication, power allocation, metering, stopping, rating, and payment settlement. Interviewers look for a durable workflow with idempotent transitions and compensating actions for partial failures.

Hints to consider:

• Model the session as explicit states: Idle, Authenticating, Authorized, Charging, Completing, Billing, Closed
• Use unique session IDs as idempotency keys so that duplicate events from retries do not create second sessions or double charges
• Stream high-frequency meter readings to a durable event log and aggregate server-side for billing rather than trusting client-reported totals
• Handle payment failures with exponential backoff retries, grace periods, and account suspension workflows that avoid leaving revenue uncollected

4. Power Management and Fairness

A single station may have 20 to 50 stalls sharing a finite grid power supply. When all stalls are occupied, the system must dynamically allocate power to maximize utilization while treating customers fairly.

Hints to consider:

• Build a site controller that monitors total power draw and dynamically adjusts per-vehicle rates to stay within grid capacity limits
• Implement fairness algorithms balancing first-come-first-served priority, fast turnaround for nearly full batteries, and minimum guaranteed power for all active sessions
• Design admission control that prevents accepting new sessions when doing so would throttle existing vehicles below acceptable thresholds
• Propagate real-time power allocation changes back to vehicles so users see accurate completion time estimates

5. Billing Pipeline and Revenue Integrity

Every kilowatt-hour delivered must be accurately metered, rated, and billed exactly once. Interviewers expect idempotent operations, auditable line items, and compensating transactions for edge cases like payment declines after energy has been delivered.

Hints to consider:

• Apply complex pricing rules (time-of-day rates, location surcharges, membership tiers, idle fees) in a dedicated rating engine that produces auditable line-item charges
• Make all billing operations idempotent using session IDs as deduplication keys
• Use the outbox pattern to ensure that metering events and billing records are written atomically
• Design daily reconciliation jobs that compare station-reported energy delivery against billed amounts to catch discrepancies

Suggested Approach

Step 1: Clarify Requirements

Confirm scale parameters: number of stations, vehicles, and geographic distribution. Ask about offline operation expectations and how long stations must function without cloud connectivity. Clarify billing complexity including time-of-day rates, membership tiers, and promotional pricing. Understand power constraints and whether stations share a fixed grid allocation. Verify real-time expectations for status updates and whether vehicles maintain persistent connections. Discuss fraud scenarios and the required security level for hands-free authentication.

Step 2: High-Level Architecture

Sketch four tiers. The edge tier consists of charging stations with local controllers managing authentication, power delivery, metering, and a local event log with cached vehicle allowlists and pricing. The gateway tier includes regional API gateways handling vehicle connections, session state, and real-time updates via WebSockets, deployed close to charging corridors for low latency. The service tier contains stateless microservices for vehicle registry, session orchestration, the billing pipeline, and availability indexing. The data tier uses Kafka for session lifecycle and metering event streams, DynamoDB for vehicle and station configuration, Redis for session state caches and fast lookups, and a relational database for financial records and reconciliation. Emphasize asynchronous, event-driven communication between tiers to tolerate partial failures.

Step 3: Deep Dive on Session Lifecycle

Walk through a complete charging session. The driver plugs in and the charger initiates a mutual TLS handshake using hardware-backed certificates. The site controller validates the vehicle against its cached allowlist and creates a session record with a unique ID. Power delivery begins and the charger streams meter readings every few seconds to Kafka, partitioned by station. A metering consumer aggregates readings and updates the session state service, which pushes cost and progress to the vehicle and mobile app via WebSocket. When the vehicle signals completion or the driver disconnects, the session enters the Completing state. The rating engine applies pricing rules and writes line items to the billing database. The payment service charges the account on file using the session ID as an idempotency key. On success, a receipt is sent and the stall is released. If payment declines, the workflow enters a retry state with backoff and notifications while still releasing the stall for the next vehicle.

Step 4: Address Secondary Concerns

Discuss real-time availability: each station publishes stall occupancy changes to a Kafka topic consumed by a service that maintains a Redis index with per-station available and occupied counts, connector types, and pricing. Mobile apps and vehicle navigation query this index. Cover power management: the site controller sums current draw across active stalls, compares against the grid limit, and broadcasts throttle commands proportionally. Vehicles receive updated power targets via their WebSocket connections. Address monitoring: chargers emit health metrics to a time-series database for anomaly detection and alerting on degraded stalls, network outages, or revenue discrepancies. Touch on disaster recovery: critical configuration is replicated across multiple regions, and in a regional failure sessions fail open with elevated risk caps, with billing reconciliation once connectivity restores.

Related Learning Resources

• Design Uber -- covers real-time location tracking, dynamic dispatch, and managing distributed stateful sessions across edge and cloud tiers
• Databases -- partitioning strategies and transactional guarantees for billing records and session state
• Message Queues -- event-driven architectures for telemetry streaming and asynchronous billing pipelines