Reference Architectures

Near-real-time analytics pipeline using Debezium CDC from PostgreSQL OLTP through Kafka, Flink stream processing, into ClickHouse for operational queries and Snowflake for business intelligence. Zero direct OLTP load for analytics workloads.

• ·Real-time operational dashboards with sub-second query latency
• ·Product analytics pipelines processing 1M–1B events/day

Three domain services: User, Order, Notification: communicating exclusively through Kafka topics using the outbox pattern. No synchronous service-to-service calls. Each service owns its own PostgreSQL database. The API Gateway handles auth and routing.

• ·Platform with distinct domain boundaries and separate team ownership per service
• ·Systems requiring independent service deployability and rollback

Payment processing with idempotency-first design: Redis idempotency store prevents duplicate charges, PostgreSQL append-only ledger is the authoritative record, the outbox pattern guarantees at-least-once payment processor delivery (the Redis idempotency store deduplicates for effectively-once), and ClickHouse provides immutable audit log for compliance.

• ·Payment processing platforms handling 10k–500k transactions/day
• ·Subscription billing systems with recurring charges

Multi-tenant platform with PostgreSQL Row-Level Security for tenant data isolation, a dedicated control plane database for tenant metadata, Redis for per-tenant rate limiting and caching, and Kafka for tenant event streaming and audit trail.

• ·B2B SaaS serving 10–5000 tenants
• ·Developer platforms with isolated workspace per team or organization

A read-optimized API tier using CDN edge caching, PostgreSQL read replicas, PgBouncer connection pooling, and Redis cache-aside. Handles read:write ratios of 10:1 or higher at 50k–5M DAU without sharding the primary database.

• ·Consumer APIs with high read:write ratio (10:1 or greater)
• ·Content platforms where most requests are GETs

WebSocket-based collaborative editing with Redis Pub/Sub for low-latency event fan-out across stateful gateway instances, PostgreSQL for durable document persistence, and Kafka for cross-region replication and external integrations. Conflict resolution via CRDT or Operational Transforms at the application layer.

• ·Real-time document editing with multiple simultaneous editors (Google Docs model)
• ·Collaborative whiteboarding and diagramming tools

Separate write and read paths for search. PostgreSQL is the authoritative store. Elasticsearch is an eventually consistent projection maintained by a Kafka-driven indexer. Redis caches frequent queries with short TTLs. Index staleness of 1–30 seconds is expected and documented.

• ·Product catalog search with faceted filtering
• ·Full-text document or content search

A single deployable application backed by PostgreSQL and Redis: the right starting architecture for most teams. Serves 0–50k users reliably with one deployment pipeline, one on-call runbook, and a team that can hold all of it in their heads.

• ·0-to-1 product validating product-market fit
• ·Internal tools and operational dashboards