All projects

Backend & Cloud

Cloud Simulation Job Platform

An Azure job platform for long-running physics simulations: FastAPI job API, queue-triggered workers that scale to zero, React + TypeScript front end

On contract to Hoare Lea, a UK engineering consultancy, I’m architecting its cloud platform for long-running physics simulations. It is live in staging and production: daylight and energy simulations came first, and more disciplines are in build.

This page stays at summary level on purpose. The platform is Hoare Lea’s internal system, so there is no code and there are no URLs here. The clips show Kaleidoscope, its front end running inside Giraffe, published with Hoare Lea’s approval; project and user names are blurred.

THE PROBLEM

Building-physics simulations are compute-heavy and slow: one job can run for more than two hours. Engineers need to submit them from the tools they already use, get a readable answer when something fails, and trust the numbers that come back.

ARCHITECTURE

  • Job API in FastAPI: submit a job, poll its status, fetch its results.
  • Workers triggered by a queue, autoscaling to zero when there is nothing to run.
  • Storage: object storage for inputs and outputs, plus a SQL job store.
  • Front end in React + TypeScript.
  • Auth: Entra ID single sign-on for people, API keys for scripts and integrations.

WHAT’S HARD

  • Long jobs. Jobs run for up to 2+ hours. A visibility timeout plus a heartbeat keeps a long job from being picked up twice.
  • Fail fast. Schema validation rejects a bad payload in seconds, before a worker spends compute on it.
  • Readable failures. A failed job returns its logs and an error a person can act on.
  • Trustworthy outputs. Results are checked against a reference standard.

DELIVERY

  • Infrastructure as code (Bicep).
  • CI/CD: staging deploys on merge, gated production releases.
  • OpenTelemetry tracing across API, worker and UI.
  • Playwright end-to-end tests.
  • Agent-native: I write the specs, context and acceptance criteria; Claude Code and Codex agents implement; I own the architecture, code review and verification, with automated gates on agent output.

STATUS

  • Live in staging and production.
  • Daylight and energy first; more simulation disciplines in build.
  • Sits next to the ML inference services I took to production for the same teams (overheating, daylight, peak solar), whose internal users grew from 5 to 50+ engineers running 500+ design iterations a month.

DEMO

The full Kaleidoscope walkthrough (86 s, with narration and captions): set the brief once, run whole-site analyses in the cloud, read radiation, vertical sky component and daylight factor results.
Transcript

Which facade on this scheme catches the most sun? Block C South, 897 kWh per square metre. Where PV pays, and where to shade.

This is Kaleidoscope, from Hoare Lea, running right inside Giraffe, in your browser. Open it beside the model and set the brief once: 40% glazing, 4.5 m zones. Preview draws exactly what gets simulated. Weather comes from the nearest station, St James’s Park, read straight from the file. Two instant checks: the sun’s path over the site, and the 25-degree rule on the neighbours.

Five analyses, from daylight factor to EN 17037. Keep the whole plot in scope, and run, in the cloud, nothing to install.

Radiation lands on every facade and roof. The facades average 571 kWh per square metre, by block and orientation. Vertical sky component on every facade, graded to BR 209: just 1% falls below 15%. Daylight factor on all 46 floors: 59% of the floor area clears 2%, every level charted. Or isolate one level across the whole site. Every run stays in history, ready to reopen.

Kaleidoscope. Design with the physics, not after it.