ARCHITECTURE CASE STUDY · ANONYMISED

A business app built on a separate data platform

I designed and built the business app in a two-part system. A separate data platform collects and stores the business data. The app reads that data through a read-only API, and each part is updated and scaled separately.

MY ROLE
Architect and lead developer for the business app. I didn't design the data platform.
SCOPE
Two apps · one read-only API
STACK
Django REST, Vue 3, MySQL, Nginx
STATUS
In production

The problem

Before the split, one app handled everything: importing data from the field-service platform, storing it, and running dashboards, pay rules and user management.

A change to a dashboard could break the data import, and a problem in one part could take down the whole app.

The design

The platform stores the data. The app reads it through a read-only API.

shared server
Health checkevery minute
Field-service platformsource of record
Data platformingests & owns data
/v1 APIread-only · versioned
Business appDjango REST · Vue 3
Staffdashboards · pay rules
Business dataplatform-owned
App databaseusers · roles · rules
  1. Field-service platformsource of record
  2. Data platformingests & owns data
    • Business data · platform-owned
  3. /v1 APIread-only · versioned
    • Health check · every minute
  4. Business appDjango REST · Vue 3
    • App database · users · roles · rules
  5. Staffdashboards · pay rules

Key decisions

  1. Read data through an API

    The app doesn't connect to the platform's database. It reads data through a read-only API. Either side can be changed without breaking the other.

  2. Handle outages

    If the platform is down, the app shows a "data unavailable" message instead of an error. A health check runs every minute and shows the outage on the monitoring page.

  3. Role-based permissions

    Each endpoint checks the user's permissions. Admins manage roles in the app instead of in code.

  4. Ready to split

    Both parts run on one server today. They can move to separate servers by changing one setting.

Outcome

  • The data platform and the app are released separately.
  • Developers can test with production data, since the API is read-only.
  • Either part can be scaled or moved to the cloud independently.

WHAT I'M LEARNING

How it could look on Azure

How each part could map to Azure services, based on what I'm studying.

Current setup and the Azure service it could map to
TodayOn Azure
Both parts on one VM behind NginxTwo App Services (or Container Apps), scaled separately
Read-only /v1 API with API keysAzure API Management in front of the platform
Minutely health-check jobApplication Insights availability tests and alerts
Shared MySQL server, separate schemasSeparate Azure Database for MySQL servers