Digital twin of a housing development

What the system does

• A navigable 3D model with 72 units coloured by commercial state, with filters by price, bedrooms and floor.
• Unit reservation by the broker, valid for 48 hours, with sale confirmation reserved for the manager.
• A TV mode for the sales floor, mirroring availability the moment it changes.
• A 3D floor plan, with the volume cut at the selected floor.
• A neighbourhood map with real points of interest and the distance to each one.
• A development portal, with tracking, team and export.

Architecture

• A React Three Fiber scene with 72 units, a late-afternoon and dusk lighting cycle, and materials driven by commercial state.
• Procedural architecture: towers are generated in code from the package data and the geometry is merged per material, which brings each tower down to about fourteen draw calls instead of thousands of boxes.
• Two implementations of the same units contract, selected by an environment variable: a local file-backed store with an EventEmitter, and Supabase over PostgreSQL with the rule in a plpgsql function.
• Business rules in SQL: reservation only of an available unit under a row lock, sale confirmed only by the manager, release by whoever reserved or by the manager, a 48-hour window, and every transition recorded in an events table.
• Real time over Server-Sent Events: the route sends a snapshot and then every change, with a heartbeat every fifteen seconds, and the browser's EventSource reconnects by itself when the stream ends.
• In database mode, a single PostgreSQL change subscription per development and per instance, fanned out through an EventEmitter to every connected client.
• Sessions in httpOnly cookies holding Supabase Auth tokens, the role resolved per development by a database function, and personal data served only to signed-in users.
• Floor-plan cutting by clipping plane: on entering Plans mode, each tower's plane descends from the roof to 1.30 m above the selected floor's slab, damped over time, with shadows clipped along with it.
• Plan linework derived from each typology's room rectangles: walls with door gaps, windows, sliding glazing, railings and leaf swings, in local metres, consumed both by the SVG drawing and by the 3D cutaway.
• A command-line ingestion pipeline: the sales spreadsheet becomes units.json, the address becomes real points of interest, relief comes from public elevation tiles, the surroundings come from OpenStreetMap, and the architect's model is converted and optimised for the web.
• One repository serves several developments: one schema-validated data package per development, with the build selected by slug and a hook that revalidates the package on every edit.

Implementation details

• Reservation happens under a row lock inside a database function, and expiry of lapsed reservations is scheduled inside PostgreSQL itself.
• A test runs twenty brokers reserving the same unit at the same time and asserts one accepted and nineteen refused.
• Nothing reproduces a real company's name, plans, renders or identity. The neighbourhood and the map's points of interest are real, taken from OpenStreetMap.