Shared foundation — Overview

This section collects knowledge that cuts across every domain: which applications make up the system, where data is stored, and the conventions/principles every domain follows.

Pages in this section

Page	Answers
Overall architecture	What are Topi / Tuke / Tux, and how do they fit together?
Database & storage	Where is data stored (SQL / Table / Blob), and what are the naming conventions?
Domain model — Aggregates & Ownership	What is an aggregate, who owns what, and where are mutation boundaries?
Timezone & DateTime	UTC storage, local display, MultiZone — a cross-domain concern.
Conventions & principles	Core principles shared by every domain.

One-minute picture

• Topi + Tuke are the two frontends; both call Tux (backend).
• Tux contains core business logic (API) and Workers (background processing through queue).
• Data is split across three stores: SQL (relational), Table (key-value), Blob (large files); Queue transports events/background work.

Why this section exists

Every domain (Subscription, Staff, Communication, Platform) stands on the same foundation. Understanding the foundation first makes the domains much easier to read — especially the anti-duplication principles and key conventions repeated everywhere.

Current implementation

• Unified settings are read through a shared snapshot across Enterprise → BusinessUnit → Org → ProgramCategory/OrgProgramCategory; client selectors only narrow server-scoped data.
• EntityEvent can use BlobRef when the fully serialized message exceeds the queue limit; required event-time payload must remain readable by the worker.
• Notification traceability uses SourceKey by business source, while EventKey/HistoryEventKey retain the idempotency role.

Real-world example: Switching from one BU to another does not re-fetch unrelated settings piecemeal; the client receives the new hierarchy snapshot and related caches are invalidated.