Production shared infrastructure. IPS planning adoption is complete for this documented production repository.
This server currently provides the PostgreSQL and Redis runtime used by all Alfares services that require these capabilities. It is intentionally consolidated because the current ecosystem workload does not justify a separate database server or instance for every service.
BUSINESS.md and SYSTEM.md, supplemented by repository architecture documentation, are authoritative.
Shared PostgreSQL and Redis infrastructure for the ecosystem. The server hosts multiple service-specific PostgreSQL databases and Redis logical separations/namespaces behind stable Kubernetes service DNS.
Each consumer remains responsible for its own data model and migrations. Shared infrastructure does not mean that unrelated services must share a database, schema, credentials, or business data.
Repository interfaces and operational boundaries are documented in SYSTEM.md and architecture records. Consumers use the shared PostgreSQL and Redis service endpoints through the documented Kubernetes service boundary.
Read AGENTS.md and repository-local architecture documentation before changing behavior.
Use documented configuration sources; never copy credentials or secret values into documentation. Credentials must remain service-specific and must be delivered through the approved secret-management path.
Follow the repository deployment boundary and production-safe rollout procedures. The current topology is consolidated, but a demanding service may be migrated to a dedicated pod, database instance, server, or cluster when capacity, availability, compliance, security, recovery, or independent scaling requires it.
Use the documented health, logging, backup, recovery, and operational checks for this repository. Monitor both the shared infrastructure and service-specific consumers for capacity and noisy-neighbor effects.
- One production database server currently hosts multiple PostgreSQL databases and Redis logical separations or namespaces.
- All database-dependent Alfares services use this shared infrastructure boundary.
- Centralization reduces operational overhead while the ecosystem remains lightly loaded.
- Stronger isolation remains available without changing the service ownership model.
Isolation can be increased incrementally: database or schema separation first, then pod-level or dedicated database instance separation, and finally a dedicated server or cluster where justified. The shared topology is a current operational choice, not a permanent architectural limitation.