scooter

At Denver Mobile App Developer, we learned early that a scooter isn't a vehicle-it's a mobile edge computer with two wheels and a battery. When a rider scans a QR code, they kick off a chain of events across embedded firmware, real-time messaging brokers, geospatial databases. And machine learning models. Our team has spent three years hardening the backend for a fleet of over 50,000 connected scooters across twelve North American cities. What follows is the architecture we've battle-tested, the mistakes we've fixed in production. And the principles that keep rides flowing even when cell networks fail.

Behind every rented scooter is a distributed system making 4,000 decisions per second-and if it fails, the scooter becomes a 30-pound paperweight.

Modern micromobility platforms must handle everything from regulatory geofencing to lithium‑ion battery safety, all while delivering sub‑second unlock commands to a vehicle on a street corner. This post breaks down the technology stack that makes it possible, with a focus on the engineering decisions that matter when a single scooter's telemetry can alert you to a failing motor winding or a rider riding the wrong way down a one‑way street.

From Kickstands to Cloud: The Scooter's Digital Backbone

Every dockless electric scooter carries a compact IoT gateway that combines a GNSS receiver, a cellular modem (usually LTE‑M or NB‑IoT), a Bluetooth 5. 0 module, and an ARM Cortex‑M class microcontroller. This gateway is the scooter's anchor to the platform, publishing state updates over MQTT and receiving commands from the cloud. In our stack, we use MQTT protocol with QoS‑1 guarantees. Because a lost "lock" command leaves the scooter vulnerable to theft.

The hardware itself is surprisingly constrained: 256 KB of SRAM and 1 MB of flash are typical. That means every firmware release must be carefully optimized to keep the telemetry loop tight. We run FreeRTOS with a custom power‑aware task scheduler that wakes the modem only when necessary, preserving battery for the scooter's motor. The gateway's primary job is to collect sensor readings-speed, odometry, battery voltage, temperature, accelerometer spikes from potholes-and to execute critical safety decisions locally, such as disabling the motor when a geofence boundary is breached.

For engineering teams building their own scooter operating system, the key design choice is where to place compute. We co‑locate sensitive rules on the embedded side (geo‑fence enforcement, over‑current protection) and keep the cloud side free for heavy analytics. This hybrid model means that even if the scooter loses cellular connectivity, it still respects no‑ride zones and stops charging if the battery temperature exceeds safe thresholds. Related: An Embedded Engineer's Guide to OTA Updates on Constrained Devices

How We Built a Resilient Telemetry Pipeline for 50,000 Scooters

When a scooter is in motion, it pushes a JSON payload of roughly 120 bytes to a regional MQTT broker every 2-5 seconds, depending on speed. At peak usage, our platform ingests over 1. and 2 million messages per minuteThat data flows through a multi‑tier pipeline: AWS IoT Core acts as the device gateway and enforces per‑device authentication via X. 509 certificates, then streams messages to Apache Kafka for decoupling. From Kafka, we fan out to a real‑time stream processor (Apache Flink) for anomaly detection and to a time‑series database for long‑term storage.

We chose TimescaleDB because it gives us the relational query surface our operations team needed-finding all scooters that exceeded 25 mph in a particular geofence last Tuesday is a single SQL query with a spatial join. The raw telemetry table alone holds over 80 billion rows, partitioned by scooter ID and time. Our SRE team wrote a custom compaction job that keeps the last 30 days of high‑resolution data hot and rolls older data into 15‑minute summary windows stored in S3 via Parquet.

The thorniest part of the pipeline isn't volume-it's out‑of‑order arrival. When a scooter moves through a tunnel, it buffers messages and replays them later. So the cloud often sees yesterday's GPS coordinates arriving this morning. We resolve this using event‑time processing in Flink with a watermark strategy based on the scooter's internal monotonic clock, not server arrival time. This prevents the rebalancing algorithm from dispatching a truck to a scooter that already moved two hours earlier.

Geofencing Architecture: Enforcing Boundaries at the Edge

City regulations often require that scooters slow down or stop entirely inside designated zones-parks, pedestrian plazas. Or school campuses. Implementing this at the firmware level demands a fast, low‑memory point‑in‑polygon algorithm that can run on a microcontroller. We ported a simplified version of the ray‑casting algorithm, with polygon coordinates downsampled using the Ramer-Douglas-Peucker method to reduce the vertex count to under 50 without meaningful accuracy loss.

However, raw GPS is too noisy for tight geofences. The scooter's cellular modem provides an accuracy of 3-5 meters under open sky. But that can balloon to 15 meters near tall buildings. To compensate, we fuse the last 10 GNSS fixes with dead‑reckoning from the wheel speed sensor and inertial measurement unit (IMU) inside the gateway, using a lightweight extended Kalman filter tuned for pedestrian‑speed movement. This brings the positioning error down to about 1. 5 meters CEP, sufficient to confidently apply a geofence at the corner of a building.

Geofence definitions themselves are managed in the cloud with GeoJSON polygons stored in PostGIS. A nightly build pipeline pushes subsets of these polygons to each scooter based on its current city assignment, using delta encoding to minimize firmware image size. The scooter checks its