Backend and infrastructure for a platform in production

Design and implementation

The problem. The platform had to split responsibilities, make deploys cheap, organise data by domain, and take on external providers without welding the core logic to any of them.

What I did. A modular backend with services separated by responsibility, a database per module, an API entry layer, caching, file storage, technical docs, and the infrastructure written as code.

Annex A · the platform, seen from far away.

How the backend is split

I split it by context, not by technical layer. Every context carries the same three folders: web with controllers and DTOs, which doesn't know the database exists; application with the use cases and the rules; infrastructure with JPA, storage and config. I copied the shape of the microservices we'd migrate to later, so the move would be mechanical.

File storage goes in through one interface. In production the files live in Amazon S3; on my machine I run MinIO in Docker against that same interface. Three config properties change and the code stays put. In the database I keep the file's key, never the bytes.

Annex B · one context up close, and the seam where the provider gets swapped.

The sheet I fill in before deploying

I don't call a deploy good until every box says where it comes from. The right-hand column is the one that costs work and the one that's worth it.

Java · Spring Boot — PostgreSQL · Flyway — Redis — object storage — Docker · Terraform · AWS — OpenAPI

APIs, states and files

The problem. A guided sign-up has to save progress, validate on the server, take files, and expose a contract clear enough for the frontend to move without asking.

What I did. The endpoints and the rules behind them: a draft that survives a closed tab, the required documents worked out from the professions the person picks, states with their history, uploads with type and size limits, and errors with stable codes instead of a generic 500. The screens were built by someone else on the team; the shared contract let us work in parallel.

Every jump is written down with who caused it and when. Nothing changes state without leaving a trace.

Identity, on the other side of a wall

Identity verification runs with an external provider, and the platform talks to it through one interface. The provider's answer comes in by webhook, signed; if the signature doesn't check out, the request doesn't get in. What the provider returns is copied into our own storage in two steps, so a half-finished copy rolls back instead of leaving a record pointing at nothing.

Phone numbers are normalised before they're stored, ages are validated on the server, and duplicate emails come back as a business error with its own code — not as a crash.

Java · Spring Boot — PostgreSQL — object storage — OpenAPI — Testcontainers

Queues, roles and auditing

The problem. A platform with users and professionals generates internal work: records and documents somebody has to review, a catalogue to keep up to date, and settings that shouldn't need a deploy to change.

What I did. The backend under that work. A review queue with temporary leases, so several reviewers can pull from it at once without stepping on each other: each one claims a batch, and whatever isn't finished in time goes back to the queue instead of getting lost. Role-based access with an identity plane separate from end users, a catalogue and settings the admin edits from the panel, and an audit trail with before and after values.

Annex C · reviewers pull in parallel, and nothing falls off the list.

Documents never leave through the front door

The panel doesn't reach storage directly. It asks the backend, the backend checks who's asking and serves the file itself. The store is never exposed to the browser — one less door, and every download passes through the same check as everything else.

Java · Spring Boot — PostgreSQL — queues · asynchronous work — roles · auditing

This job taught me to build the backend of something real: APIs another team consumes, rules that hold on the server, integrations that fail without taking the rest down, deploys, and the internal tools that keep the operation running.