Platform
Architecture
A modular monolith with mechanically enforced boundaries — one binary, one database, and dependencies that degrade rather than fail.
Written from docs/architecture.md, docs/solution-design.md — the 34 decision records behind this are indexed separately
The platform is a modular monolith. One Go binary runs in several modes — API server, worker, migration, and others — against one PostgreSQL database. Modules have boundaries, and the boundaries are enforced mechanically rather than by convention.
Enforced boundariesPermalink to this section
A module may not reach into another module's internals. This is checked in the build rather than reviewed in a pull request, because an import that shouldn't exist compiles perfectly well and is only ever caught by someone remembering. The enforcement is what stops a monolith becoming a single tangled unit over time.
One binary, several modesPermalink to this section
The same artefact serves the API, runs background jobs, applies migrations and performs operational tasks. Shipping one binary means the version running the worker cannot drift from the version running the API — a class of incident that needs no further mitigation because the shape prevents it.
Background workPermalink to this section
Jobs run on a Postgres-backed queue whose tables live in the same database as the domain. A job that enqueues in the same transaction as the work that caused it either both happens or neither does — which for screening a newly onboarded customer is the difference between a guarantee and a hope.
Optional dependencies degradePermalink to this section
Where an external dependency is optional, its absence degrades the feature rather than failing the platform. An unconfigured identity-verification provider returns an explicit not-configured outcome; an unconfigured watchlist source records a failed refresh. Neither takes the system down, and neither is reported as success.