TDKSOFT Backend Platform

Context

TDKSOFT's client applications all need the same building blocks: authentication, a database, file storage, messaging. Rebuilding them per project, or relying on a third-party cloud service, is expensive and causes incidents.

Problem and constraints

• A client application should only know a URL, a project ID and keys, never the internal topology.
• Strong isolation between clients.
• Open-source components, hostable on our own infrastructure.

Architecture decisions and trade-offs

Ten architecture decisions, one per building block:

• One database per project: stronger isolation than a shared schema, at the cost of more databases to operate.
• A control plane in Java/Spring with a hexagonal architecture.
• Keycloak for identity, PostgREST for the data API, SeaweedFS for object storage, NATS JetStream for messaging, APISIX as the gateway.
• Infrastructure as code: OpenTofu, Ansible, Helm and Argo CD; secrets encrypted with SOPS and age.

Security and delivery

• Phased delivery with human approval at every gate: 10 phase reports versioned in the repository.
• GitHub Actions CI, a Helm chart for the control plane, secrets never in plain text in Git.

Results and current state

• First real deployment done (phase 9); no client application runs on the platform in production yet.
• 66 test files in the repository.