Integration
Type: Cross-cutting
Schema: integration
Tables: 2
Primary source: documents/doc-21-integration-schema-architecture.md
Decisions: 85, 86, 88, 89, 96, 113, 114
Purpose
The integration module provides the shared infrastructure through which the platform communicates with external services -- payment processors, infrastructure provisioning systems, tax computation providers, and notification delivery services. It is deliberately thin: only two tables reside here, both in the integration schema (Decision 113), both structurally standalone. The module's architectural significance lies not in its table count but in the namespace strategy it establishes (Decision 86: schema-per-provider) and the boundary methodology it codifies for distinguishing domain concerns from integration concerns. Provider-specific schemas (stripe, polar, nextcloud, tax, notify) are designed at implementation time, not in the data model reference; this module governs only the shared plumbing that all providers depend upon -- idempotent webhook capture and transactional outbox delivery.
Tables
| Table | Purpose |
|---|---|
webhook_events |
Idempotent inbound webhook capture. Partitioned monthly by received_at, matching the audit log partitioning pattern. Deduplication enforced via UNIQUE(provider, provider_event_id). |
integration_outbox |
Transactional outbox for outbound integration actions. Written atomically with domain state changes to guarantee no integration trigger is lost. Supports exponential backoff and dead letter handling. |
Quick Links
- Model Reference -- DDL and table descriptions
- Architecture -- Deep-dive documentation
- Module Companion -- Decisions and open issues
- Interfaces -- Cross-module dependencies