Data Layer Overview

Olly uses a database-per-service pattern: every Go microservice owns its own dedicated PostgreSQL database within a shared PostgreSQL cluster (Cloud SQL for PostgreSQL in the GCP production target, a single Postgres container in dev and local). There are no cross-schema foreign keys and no cross-service joins. Each service accesses only its own schema, enforcing hard isolation between domains. Schema names match service names: claims, eligibility, enrollment, billing, provider, notifications, policy_admin, consent, documents, triage, care, broker_api, group_scheme.

Asynchronous communication between services flows exclusively through Kafka (Strimzi-managed on GKE in the GCP production target, a Kafka container in dev and local). When a service needs to notify another of a state change - a claim adjudicated, an enrollment activated, a payment received - it publishes an event to a well-known topic. Consuming services react to those events and update their own state. This keeps services fully decoupled at the data layer: no service ever reads from another service's database. The Kafka Event Catalog documents every topic, its producers, consumers, and payload schema.

Schema migrations are managed by Goose. Each service has a migrations/ directory containing numbered SQL files (0001_create_schema.sql, 0002_create_charges.sql, …). On startup, the service runs all pending migrations automatically before accepting traffic. Local development uses the same migration path as production - there are no separate seed scripts or schema definitions. A Valkey (Redis-compatible) cache runs alongside the services for session data, claims-status caching, rate limiting, and Kafka consumer idempotency keys.