ADR-0001: Modular monolith on a monorepo instead of microservices

• Date: 2026-09-18
• Status: Proposed (seed — awaiting the owner's approval)
• Deciders: the owner, Claude (seed)
• Tags: infra strategy

Context

The raw idea consists of six domains (payments, presence, social, ads, sites, add-ons). The biggest risk is fragmentation: six products with separate tables and authentication systems. The team is small at the start.

Decision

We build a single modular monolith: one database, one authentication system, one event bus, and every domain as a package under modules/ that implements ModuleManifest.

• No standalone service except for heavy, stateless tasks (containers).
• Boundaries between modules are enforced by the contract and by lint, not by the network.

Consequences

• Positive — development speed, atomic transactions across domains (payment + invoice + event), a single deployment.
• Negative — requires discipline at the boundaries; at large scale a module (for example ads) may be split out later.
• Revenue impact (SAR / month, confidence) — indirect: lowers development cost and shortens the path to first revenue (high confidence).

Rejected alternatives

• Microservices from day one: operating and coordination cost a small team cannot carry.
• Separate products behind a unified UI: reproduces the fragmentation we are fighting.

References