LunaLabs

Data infrastructure · 2025

Property Index

Architected for an idle cost of approximately zero.

The first requirement was not a feature. It was that the system cost approximately nothing while nobody was using it — which turns out to constrain the architecture more tightly than any functional requirement, and to rule out most of the obvious choices.

Status
Architecture
Domain
Cloud architecture
Role
Architecture
Year
2025

Stack

  • Azure Container Apps
  • SQL Serverless
  • Functions
  • Blob
  • Maps
  • Event Grid
  • Entra ID

A real-estate index whose defining constraint is economic: every component must scale to zero or auto-pause, so an idle system costs nothing.

01

The constraint that chose the database

A serverless relational database was selected over a richer geospatial engine specifically for its auto-pause economics, accepting weaker native geospatial ergonomics and filling that gap with a dedicated mapping service.

It is a deliberate trade recorded as a trade — the cost model was the load-bearing requirement, so it won.

02

Auto-pause has a design consequence

A serverless database only pauses with zero open sessions, which means connection lifecycle is not an implementation detail — a well-meaning connection pool that holds an idle handle keeps the database warm and silently deletes the entire economic argument for the architecture.

The design therefore specifies that idle connections must drop, and accepts the resume latency that follows.

03

Latency is the currency being spent

Everything scaling to zero means everything has a cold start: the database resumes in about a minute, the container spins up, the function warms.

That is the price of the cost model, and pretending otherwise would produce a design that fails its first real user. The system is therefore specified around it — first-request behaviour, what the user sees while a component wakes, and which paths are allowed to be slow.

04

Agent relationships are in the schema, not bolted on

The data model carries agent-linking tables from the outset, because the planned outreach flow — contacting agents and tracking delivery, bounce and open events — is a relational problem, not a messaging one.

Designing it into the schema rather than adding it later is what keeps the event stream joinable to the listings it concerns.

05

An architecture document is a deliverable

The project sits deliberately at the architecture stage with the decision record complete: the stack chosen, the schema written, the trade-offs and their reasoning captured.

Implementing before that reasoning is written down loses the cost-model context that justified every component choice — and it is the context, not the component list, that is hard to reconstruct later.

Pipeline

Scale-to-zero path

Stage Can reject

  1. 01

    Request

    Cold entry

  2. 02

    Container wake

    API up

    Consumption tier

  3. 03

    DB resume

    Connection

    ~1 min from paused

  4. 04

    Query

    Listings

  5. 05

    Idle drop

    Back to zero

    Held handles break the cost model

Skills exercised

What the build
actually demanded.

Against the corpus · 15 systems

  • Stack breadth 7
  • Design decisions 5
  • Pipeline stages 5
  • Decision gates 1

This system Corpus median

Cloud design

  • Scale-to-zero component selection across a full stack
  • Consumption-tier compute and event-driven glue
  • Managed identity and directory-based access
  • Transactional email with delivery-event handling

Data

  • Relational schema for listings, agents and relationships
  • Geospatial strategy under a non-geospatial engine
  • Connection lifecycle designed around auto-pause
  • Cost modelling as a schema-level constraint

What it establishes

  • Idle cost ≈ zero

    Every component scales to zero or auto-pauses

  • Trade recorded as a trade

    Geospatial ergonomics exchanged for economics

  • Connection lifecycle specified

    Idle handles would break the cost model

  • Cold start budgeted

    Wake latency designed for, not discovered