Skip to content
back to achievements

Case study · Stadium Rover

Client project · AugmentProject period2024 – 2025

Distributed backend

Architected a distributed backend that separated the mobile application's core API from a dedicated AI service, enabling independent development and operation of application and AI workloads.

01

Why

The app needed ordinary operations (users, content, tickets) and AI work (itineraries, review summaries). The AI work is slower, changes often and uses different tools, and it shouldn't interfere with the core operations.

02

Decision

I split the backend into two services for isolation. The core API is written in Node.js and Express. The AI service is in FastAPI and Python, and more machine-learning work can be added there later. The core service is the main component: the mobile app talks only to it, and it manages the AI service. A request that needs AI goes mobile app, core service, AI service. The two services talk with authenticated machine-to-machine calls, and the API keys rotate automatically.

Two practical reasons backed the split:

  • Tooling. At the time, LangChain and LangGraph were not fully supported in JavaScript.
  • Familiarity. Fewer people on the team were comfortable with Python. Separate services let the people who know Python work on the AI piece, and the JavaScript people keep working on the backend without any problem.

How it fits

Hover or focus a box for the story behind it.

The mobile app talks only to the core API. The core API calls the AI service. The two services authenticate with keys that rotate automatically.RequestKeyed callOne extra network hopNew key every 6 months, automaticThe app never calls the AI service directly. Every request goes to the core API first.Mobile app Talks only to coreThe main component. It handles the ordinary operations and manages the AI service.Core API Node.js, ExpressKept separate for isolation and because LangChain and LangGraph were not fully supported in JavaScript. More machine learning can be added here later.AI service FastAPI, Python

The mobile app talks only to the core service. When a request needs AI, the core service calls the AI service and returns the result.

03

Alternatives considered

A single service was the first thought. I insisted on separating them because of the isolation and the tooling.

04

What I built

Architected a distributed backend consisting of a core API service and a dedicated AI service, separating standard application functionality from AI-specific workloads.

The core service acts as the primary backend interface for the mobile application. Requests requiring AI functionality are routed through the core service to the dedicated AI service:

Mobile Application → Core Service → AI Service

Implemented secure machine-to-machine communication between the services, including authentication and automated API-key rotation.

This architecture provided a clear separation between core application responsibilities and AI workloads while maintaining controlled communication between the services.

05

Trade-offs

  • A network hop. Every AI request goes from the core layer to the AI layer, which adds a hop.
  • Key rotation. The keys between the services rotate automatically every six months, which is one more process to keep running.

06

Outcome

The application and AI work can be developed and operated independently, and each team works in the language it knows.

Technologies