Container Architecture¶

Executive Summary¶

Container Architecture defines the C4 Level 2 logical container view for Algosure. It identifies the major applications, services, data stores, AI containers, integration containers, and external dependencies that support the Algosure system context.

Why This Exists¶

The C4 Level 1 system context treats Algosure as one system. C4 Level 2 decomposes Algosure into logical containers so architecture, engineering, AI, data, security, and integration teams can reason about responsibility without prematurely deciding final deployment topology or infrastructure configuration.

Owner¶

The owner is the Chief Product Officer and Enterprise Architect.

Business Value¶

The container view gives teams a shared architecture map for DDD alignment, AIOS orchestration, multi-tenant security, event-driven coordination, data ownership, and external integration governance before code and infrastructure decisions are finalized.

C4 Level 2 Scope¶

At C4 Level 2, a container is a separately meaningful application, service, data store, or gateway. In this document, container does not mean a Docker image, Kubernetes workload, cloud service, or final deployment unit.

flowchart TB
    Mobile[Mobile App]
    Web[Web App]

    Backend[Spring Boot Modulith Backend]
    AIOS[AI Orchestration Service]
    AIGateway[AI Provider Gateway]
    Integration[Integration Gateway]
    Notify[Notification Service and Channel Adapters]

    Postgres[(PostgreSQL)]
    Redis[(Redis)]
    ObjectStore[(Object / Document Storage)]
    Search[(Search Index)]
    Vector[(Vector Store / Semantic Memory Store)]
    Warehouse[(Future Analytics Warehouse)]

    External[External Systems]
    Payment[Payment Provider Integration]
    Providers[AI Providers]

    Mobile --> Backend
    Web --> Backend
    Backend --> Postgres
    Backend --> Redis
    Backend --> ObjectStore
    Backend --> Search
    Backend --> Vector
    Backend --> AIOS
    Backend --> Integration
    Backend --> Notify
    Backend --> Warehouse
    AIOS --> AIGateway
    AIGateway --> Providers
    Integration --> External
    Integration --> Payment
    Notify --> External

Logical Containers¶

Container	Type	Primary Responsibility
Mobile app	Application	Provides mobile access to tenant-scoped tasks, approvals, notifications, evidence, executive views, and operational workflows.
Web app	Application	Provides richer tenant workspace, administration, dashboards, document work, workflow operations, and executive views.
Spring Boot Modulith backend	Core application container	Owns the modular monolith, bounded context modules, application services, domain rules, workflow coordination, event publication, security enforcement, and API contracts.
PostgreSQL	Data store	Stores domain-owned transactional data, tenant state, workflow state, audit references, and authoritative Algosure records.
Redis	Data store	Supports logical caching, ephemeral coordination, rate limiting, session-adjacent state, and short-lived workflow support where approved.
Object / document storage	Data store	Stores tender documents, compliance evidence, generated documents, signed documents, attachments, exports, and other binary or file-based evidence.
Search index	Data store	Supports search and retrieval across opportunities, documents, suppliers, compliance records, contracts, knowledge, and operational history.
Vector store / semantic memory store	AI and data store	Supports semantic retrieval, contextual memory, embeddings, and AIOS memory workflows under governance.
AI orchestration service	AI container	Coordinates AIOS execution, Digital Professional delegation, context assembly, reasoning workflow, confidence, approvals, and explainability evidence.
AI provider gateway	AI integration container	Mediates access to external AI providers while preserving policy, tenant context, provider abstraction, safety, traceability, and usage controls.
Integration gateway	Integration container	Mediates external tender, government, compliance, productivity, funding, marketplace, and country-specific integrations.
Notification service and channel adapters	Integration container	Coordinates notification intent and channel delivery adapters for email, messaging, and other governed channels.
Payment provider integration	Integration container	Handles logical payment-provider interaction for billing, payment status, subscription transactions, refunds, and commercial events.
Future analytics warehouse	Data container	Supports future analytical workloads, historical reporting, cross-domain insight, and management information without weakening domain ownership.

Core Alignment¶

Architecture Principle	Container Architecture Meaning
Spring Boot Modulith core	The backend remains the core application container and primary host for bounded context modules.
DDD alignment	Domain ownership is expressed inside backend modules and protected by contracts, events, and persistence ownership.
Multi-tenant by design	Tenant context must flow through applications, backend, AI, data stores, integrations, notifications, and audit records.
Secure by design	Access, authorization, consent, secrets, provider use, external calls, and data access must be governed at container boundaries.
Event-driven	Domain-significant changes should move through governed business events rather than hidden coupling.
AIOS aligned	AI orchestration supports Digital Professionals, memory, explainability, approval gates, and audit evidence without owning source domain facts.

Container Boundary Rules¶

Rule	Meaning
Backend is the domain authority	The Spring Boot Modulith backend owns domain rules, source fact decisions, workflow coordination, and authoritative commands.
Frontends do not own business logic	Mobile and web apps present experiences and collect input; they do not own domain rules or source facts.
Data stores are not shared ownership	Each data container supports defined responsibilities; ownership still belongs to Domains and governed services.
AI containers do not bypass Domains	AI orchestration and semantic memory must request authorized context and return outputs through governed workflows.
Integrations do not own internal meaning	Integration containers translate external interactions into domain-owned interpretation and events.
Analytics is downstream	The future analytics warehouse consumes governed data products or events and does not replace transactional domain ownership.

Non-Implementation Boundary¶

This document does not define:

Deployment topology.
Docker images.
Kubernetes resources.
Cloud provider services.
Database schemas.
API endpoints.
Event payloads.
Queue or broker products.
AI model selection.
Infrastructure-as-code configuration.