Status. Proposed design only. Nothing in this vault is DG client approval. No application, service or test has been executed; every scenario is Not executed. Fees and dates are open.
System components
Source: Balanced architecture rev 3, pp. 3, 8–9. See also API-and-Request-Pipeline, Deployment-and-Operations.
Modular monolith. One web + server API codebase, one background worker from the same codebase, one private PostgreSQL database. Module boundaries are internal; separate business microservices are not required.
flowchart LR MB[Member browser<br/>responsive English UI] -->|HTTPS session| API[Web + server API<br/>single modular codebase] DB[DG admin browser<br/>membership tools] -->|HTTPS session| API IDP[Identity provider<br/>vendor to be agreed] --> API API -->|scoped data access| PG[(Private PostgreSQL<br/>records, outbox, delivery, audit)] API -->|committed work| W[Background worker<br/>same codebase] PG --> W W --> EM[Email provider<br/>vendor to be agreed]
| Module | Responsibility |
|---|---|
| Identity and company access | Verify session, active membership and role on every request; one company per user in Balanced; identity provider choice is Q09 / D08 |
| Opportunities and discovery | Draft, review, publish, immutable versions, structured validation, full-text search, transparent rule ranking; audience filtering before ranking or counts |
| Engagement and tracking | Questions, approval-backed interest, participant-scoped discussions, assignment, next actions; no contract execution or payments |
| Notifications and administration | Transactional outbox, immediate delivery, retry/recovery, membership approval/revocation, scoped audit; DG has no private-message body access by default |
Provider credentials stay server-side. The browser and any model receive no database service credential. Provider vendors and region are DG decisions, not choices made here.
Implementation recommendation (not a provider selection): React/Next.js with TypeScript, server API and PostgreSQL.