The scale challenge
Facility management is a scale business. A management company that starts with one 50-unit estate might grow to 20 properties and 5,000 units within two years. The platform that worked fine for 50 units — a single database, a single server, synchronous everything — starts to creak at 5,000. At 10,000 units, it breaks.
Haag was designed for scale from day one. Not because every customer needs 10,000 units today, but because the architecture decisions you make early are expensive to reverse later.
Database design
The database is the foundation. Haag uses PostgreSQL with a schema designed for multi-tenant isolation:
- Property-scoped queries — every query is scoped to a property ID, so the database can use a composite index on (property_id, ...) to narrow results quickly. A query for "all service requests in Building A" hits an index, not a full table scan.
- Partitioning by property — for high-volume tables (meter readings, visitor logs, service requests), data is partitioned by property. A query for one property only scans that property's partition, not the entire table.
- Read replicas — read-heavy operations (dashboards, reports, article lists) hit read replicas, while writes go to the primary. This keeps the primary responsive even under heavy read load.
API architecture
The Haag API is built for efficient data transfer:
- Field selection — the API supports field selection, so a list of articles returns only the summary fields (title, excerpt, cover image), not the full body. This keeps responses small and fast.
- Pagination — list endpoints are paginated. The blog list returns 6 articles per page, not 500. The article-list section on a landing page returns a configurable limit (default 5).
- Caching — public content (articles, case studies, landing pages) is cached at the CDN edge. A request for the blog list from a user in Lagos hits the Lagos edge node, not the origin server.
- Async processing — long-running operations (bulk imports, report generation, notification blasts) are queued and processed asynchronously. The API returns immediately, and the client polls or receives a webhook when the job is done.
Mobile app performance
The mobile apps are designed for low-bandwidth environments:
- Offline-first — the apps cache data locally and sync when connectivity returns. A security guard can log patrols even when the internet is down.
- Image optimisation — images are served via Cloudinary with automatic format negotiation (WebP for modern browsers, JPEG for older ones) and responsive sizing. A cover image that is 2MB on desktop is 200KB on mobile.
- Delta sync — the apps sync only changed records, not the full dataset. If a resident's payment status changes, the app receives a 1KB delta, not a 50KB full refresh.
Monitoring and alerting
Scale is not just about handling load — it is about knowing when things go wrong. Haag monitors API response times, database query performance, and error rates in real time. When a metric breaches a threshold (e.g. API p99 latency above 500ms), the on-call engineer is alerted within 60 seconds.
The result
Scale is not a feature you add later. It is an architecture you build from the start — because by the time you need it, it is too late to retrofit.
Today, Haag handles portfolios with 10,000+ units across multiple properties, with API p99 latency under 300ms and 99.9% uptime. The architecture that was designed for scale on day one is the architecture that makes scale invisible on day 1,000.
