ADR-001 Modular monolith first
| Status | Accepted |
| Date | 2026-09-20 |
| Deciders | Titip product authority (control plane) |
Context
Titip has several sensitive domains: identity, vaults, life check, delivery, notifications, audit. Splitting each into a service on day one would freeze contracts before the domain is stable and would create a distributed monolith: many deployables, one tangled release path.
The product still needs hard boundaries so that a later extraction is possible.
Decision
The first wave of repositories is:
control-plane, app, web, backend, ai, infrastructure, knowledge.
backend is a modular monolith. Modules:
auth, users, contacts, vaults, assets, policies, lifecheck, escalation, releases, notifications, audit, admin.
vault, life-check, delivery, and notifications are modules, not repositories, until traffic, team ownership, or a security boundary justifies extraction.
Modules communicate through in-process interfaces that match contracts/. They must not reach into each other’s tables. Extraction should be a deployment change, not a domain rewrite.
app and web contain no domain authority. They call backend (or a stub that implements the same contract, during the clickable prototype).
Consequences
- One database is acceptable in the prototype and functional MVP. Restricted vault bytes are still encrypted (ADR-006).
- Operational isolation (separate keys, separate network) is weaker until extraction. Compensating controls are encryption, audit, and no standing employee access to plaintext.
- A team that wants a new service must show the boundary in this ADR series first, not open a repository and invent a contract.