Platform overview

Core principle

Postgres for truth. Kafka for movement. Snowflake for intelligence. One app for everyone.

Layer summary

Layer	Technology	Purpose
OLTP store	Postgres / Neon	Source of truth — ledger, accounts, KYC, payments
CDC	Debezium	Captures all Postgres changes to Kafka
Event stream	Kafka	Domain events, asynchronous propagation
Analytics / ML	Snowflake + Cortex	Risk models, regulatory reporting, fraud, categorisation
Write-back	Internal API	Snowflake results → Postgres for operational use
API	Gateway + microservices	All capability exposure — versioned, authenticated
Frontend	React / Next.js	Single codebase — customer + back office
Infrastructure	AWS (ap-southeast-2/4)	NZ/AU data residency, multi-region

Transaction path (synchronous — must complete in milliseconds)

Customer action → API Gateway → Service → Postgres
                                        ↓
                               Pre-flight checks:
                               - Balance (Postgres)
                               - Daily limits (Postgres)
                               - Fraud score (Postgres — pre-computed from Snowflake)
                               - Sanctions (Postgres — materialised list)

Everything on the transaction path reads from Postgres only. No Snowflake calls inline.

Analytics path (asynchronous — seconds to minutes)

Postgres write → Debezium CDC → Kafka → Snowpipe Streaming → Snowflake
                                                             ↓
                                              Dynamic tables compute:
                                              - Customer risk scores
                                              - Fraud model scores
                                              - Capital / liquidity ratios
                                              - AML typology scores
                                              - Regulatory returns
                                                             ↓
                                              Write-back API → Postgres
                                              (operational scores available
                                               within 60s of event)

Key architectural constraints

Every engineer in every repo must know these five rules:

1. No Snowflake on the transaction path — read Postgres write-back values instead
2. Ledger is append-only — corrections via reversal entries, never edits
3. All secrets in vault — no secrets in code, config files, or environment variables
4. No standing production access — all sessions time-limited via PAM
5. All actions logged — immutable audit trail, no exceptions

Related decisions

ADR-001 · ADR-002 · ADR-003 · ADR-004 · ADR-005 · ADR-006

The five constraints above are derived from architectural principles AP-001 through AP-004 and AP-008. Use perspectives to evaluate how well a proposed change holds up against these constraints.