By Nihal Gonsalves & Jay Morrow

You may know MOIA from our eye-catching vehicles driving around Hamburg, or from our apps — but what’s behind the scenes at MOIA Engineering?

MOIA runs a ride-sharing service in Hamburg and Hanover, with our own apps, backend services, drivers, and vehicles, that all come together to provide a fully-integrated, affordable, convenient, and modern ride-sharing experience.

Through this series of blog posts we’d like to show you what makes MOIA run, demystifying some of the magic behind how our technology runs the ride-sharing service for the cities of the future.

The MOIA+6 is at the core of our mobility experience. To run a dynamic ride-sharing service, we equip our vehicles with an embedded computer, a remote unlocking module, a telemetry unit, a WiFi router and two connected displays: an info-screen for passengers and a tablet for navigation.

Every MOIA+6 communicates multiple times a second with our cloud platform over MQTT (AWS IoT) to send information on over a hundred different metrics including sensor data, geolocation data, and automotive telemetry (down to the angle of the gas pedal!). Our backend systems continuously tell the vehicle about new passengers, routes, and up-to-date travel times for all pickups and drop-offs. We also make use of IoT Greengrass to run a small slice of AWS in the vehicles themselves, making for a seamless experience even through momentary connectivity hiccups like driving through the Deichtor-Tunnel in Hamburg.

Hidden away in the cloud are our purpose-built microservices running on various AWS compute environments, keeping track of every vehicle and passenger request that comes in, pooling passengers, routing vehicles, and equipping the MOIA Operations teams with the tools they need to run an excellent, highly-available service. These are built with various technologies best suited for the job at hand. For compute, we use Kubernetes on AWS EC2, AWS Fargate, and AWS Lambda, depending on the workload. We tend to stick to fully-managed AWS services by default (including DynamoDB, RDS, IoT, Kinesis, S3, API Gateway, and Greengrass), making exceptions when it makes sense. Each team chooses a programming language suitable to the problem, mainly (but not limited to) Scala, Kotlin, and Golang.

These microservices communicate primarily asynchronously using domain events, and all come together to provide a consistent, unique experience for passengers, as well as our drivers and hub staff.

Dispatching keeps track of our entire fleet, communicates frequently with our vehicles, and (as the name implies) dispatches the best vehicle to every customer. It knows exactly where each vehicle is, which passengers need to be picked up and dropped off, and when the vehicle needs to return to the hub (to recharge or to end a driver’s shift on time). Dispatching makes heavy use of AWS IoT to have up-to-date telemetry data.

To serve a trip request, Dispatching selects a pair of virtual stops from the MOIA Stop Network most suitable for the passenger’s origin and destination. It then asks Dynamic Routing for an optimal route according to various criteria including the estimated travel time based on the traffic situation, pooling efficiency (passengers pooled in a single vehicle), and the drop-off time promised to other passengers.

Vehicles are also constantly re-allocated by Dispatching to optimal areas and are periodically sent back to the nearest hub with free charging points for recharging when required, as well as when the end of a driver’s shift is upcoming.

If you’ve ever used MOIA, these are the two services that work directly with the app to make your trip possible. From the moment you hit the “Get Offer” button, Trip Booking takes over and coordinates the saga of everything that needs to come together within seconds to guarantee you a great trip.

Trip Booking communicates with all the other backend services to present you with a suitable route, fetches a dynamically-calculated price from Pricing (depending on the distance, weekday and time), and comes back with an ETA and your pickup and drop-off stops. Once you slide-to-order, it confirms the validity of your payment method with Payment and confirms your MOIA with Dispatching.

The Payment team works with our payment providers to ensure a seamless payment experience no matter what customers choose to pay with: credit or debit card, Apple Pay, Google Pay, or PayPal. It also keeps up with the various compliance requirements such as the EU PSD2 and SCA (Strong Customer Authentication).

The hub teams work round-the-clock to optimise supply by keeping vehicles in tiptop shape, charged, and ready to go, and planning driver shifts optimally. The Fleet and Employee Management teams provide the technology to make these processes efficient, keeping track of various workflows such as service area and stop network management, shift planning, damage reporting, vehicle hardware management, TÜV inspections, maintenance, and everything else. This is exposed via a React frontend and a combination of REST and GraphQL.

The Fleet service additionally provides a keyless experience to drivers by utilising the remote unlock and telemetry unit in the vehicles.

There isn’t enough space in one blog post to talk about everything that makes MOIA run — including the mobile frontends (that utilise Kotlin, Swift and Dart — Flutter), DevOps, incident handling, and the many small services that have so far gone unmentioned.

In the coming months, we want to tell you more about how we work at MOIA, including our agile processes, engineering culture, and of course, the many team events, parties, and office dogs.

If what we do sounds interesting to you, and you’d like to work on an innovative, sustainable, and affordable mobility service for the cities of the future, learn more about open positions on our career page

Our code on the road to future mobility.