Legal data has borders. A law firm in Dubai and a law firm in Frankfurt answer to different regulators, follow different residency rules, and expect different things about where a client file is allowed to sit. For a legal platform, "where is my data?" is not a question you answer with a footnote.
From the start, HAQQ ran in more than one region. But for a long time each region also owned its own users. That worked while every firm lived in one place. It stopped working the moment a person needed to reach a region other than the one that created them: a firm with offices in two jurisdictions, or a mobile app that has to find whichever region your workspace lives in.
So we rebuilt how HAQQ knows who you are. This post describes the shape we chose and what we learned building it.
Regions are estates, not shards
Experimente HAQQ AI grátis
Experimente a redação e pesquisa jurídica com IA
Each HAQQ region is a complete, separate estate. It has its own application and background jobs, its own database, its own document storage and search index, and its own logs and metrics. Regions are not slices of one shared database. They are independent installations that happen to run the same software.
One rule sits underneath all of it: a workspace's records and documents are stored in its home region, and no product action moves them to another region's estate. We treat that sentence as a legal commitment rather than an engineering convenience. Every design decision below had to keep it true.
One identity that holds nothing regional
Above the regions sits a new identity service. It answers three questions: who you are, which region each of your workspaces lives in, and what your plan entitles you to. It doesn't hold documents, matters, chats or anything else a client produces. Those are hosted in the region.
The identity service also publishes the list of regions: where each one's API lives and whether it is accepting new workspaces. When you create a workspace, that is how HAQQ decides where it goes. When you open the app, that is how it finds your work.
A session that travels
The hardest lesson came from sessions. A session cookie is only as portable as the place that issued it. Even when two regions can both read a cookie, the user it names exists in one region's database and not the other's. The cookie arrives intact and still means nothing.
The fix was to stop carrying sessions in cookies between regions. When you sign in, the identity service gives you a signed access token. Every region holds the matching public key and checks the token itself, without calling back to identity. The same token works in every region, and checking it doesn't depend on any other service being reachable.
Keeping everything in sync with webhooks
Identity and the regions still need to agree on some things: your profile, your entitlements, the credits your firm has bought. Those changes travel as signed webhook events, with a few rules:
- Store first, act second. Every event is written down before anything happens because of it, so a crash or a retry never loses one.
- Apply once. Each event carries an idempotency key. A duplicate delivery is recognised and ignored.
- Retry what can succeed. A temporary failure is retried from the stored record. A permanent refusal is not retried blindly. It is surfaced for someone to look at.
We also track credit grants separately from other events. A stuck profile update means stale data for a few minutes. A stuck credit grant means a customer who paid and has nothing to show for it. Those deserve different alarms.
Logs stay home
The obvious way to monitor many regions is to ship every log line to one central store. We decided against it. Application logs carry request paths, user identifiers and error payloads, which is regional content. Centralising them would move through the back door exactly what the product refuses to move through the front.
Instead, every region keeps its own logs and metrics. Our dashboards query each region in place over a private network. We still have one place to look, and the logs stay where they were produced.
A region is a few files
All of this only holds if regions are consistent, and consistency doesn't survive copy-and-paste. So regions now live in a single control-plane repository. A region is a handful of files describing what runs there. Names are derived from those files rather than typed by hand, so two regions can't disagree about what something is called.
Production releases go through one reviewed gate. When we moved existing environments into this setup, we proved that every configuration value the new system would deliver matched what was already running, compared by hash and never printed. Only after that did we start correcting anything. Migration proves equivalence. Correction changes behaviour. Mixing the two means that when a check fails, you can't tell which one broke it.
Our own compute
HAQQ's OCR pipeline and the models we host in-house run on GPUs we operate ourselves.
What we learned
- Design sessions to travel. Multi-region doesn't cause the session problem, it exposes it. Every region you add makes it more likely, not less.
- A 200 can lie. A proxy will happily answer "OK" with nothing behind it. Every health check we write now asserts on what came back, not just the status code.
- Re-test "not ready yet." A comment in a config file said a dependency wasn't serving production. It had been serving for weeks. Believing it cost us a day.
- Prove before you fix. Moving a system and improving it at the same time makes every failure ambiguous. Do one, then the other.
What's next
Adding a region is now a reviewable change in one repository rather than a project. That matters to us because the firms we serve keep asking the same question in different jurisdictions: can my data stay here? We want the answer to be yes, quickly, and true by construction.
