You're restructuring a portfolio platform's backend for an architecture firm in Helsinki — evaluating and implementing GraphQL, adding caching with invalidation, optimizing database performance, containerizing with Docker Compose, and building observability with OpenTelemetry.
The discipline skills: GraphQL resolvers with DataLoader, Redis caching with explicit invalidation, database query optimization with EXPLAIN ANALYZE, multi-stage Docker builds, Docker Compose for multi-service environments, OpenTelemetry distributed tracing, Grafana dashboards, and first cloud deployment to Azure.
The AI-direction lesson: multiple AI failure domains activate at the same time. AI generates GraphQL resolvers that produce invisible N+1 queries. It generates caching without invalidation strategy — a stale data generator. It generates OpenTelemetry traces where every span is a direct child of the root, losing the actual call hierarchy. It generates single-stage Docker builds that ship dev dependencies to production. None of these failures show up in the response payload or the test suite. You catch them by measuring: checking the database query log, verifying cache invalidation, reading the trace hierarchy. And you govern AI's tool access — deciding whether the database connection should be read-only, whether that third-party MCP server is trustworthy.
Your Role
You restructure a working platform's backend. The code runs. The data is correct. But every page load fetches everything, the database runs hundreds of queries when a handful would do, and the hosting costs reflect the waste.
You evaluate GraphQL, build it, add caching with explicit invalidation, optimize the database, containerize the multi-service environment, add distributed tracing, and deploy to a cloud service. Four areas of new terrain at once — they're inseparable in practice.
What's New
Last time you fixed state architecture and wrote your first project memory file for a river eco-tourism company. You built AI infrastructure from scratch and experienced the difference between sessions with and without it.
Three things change.
You restructure, not fix. The booking system had a bug. This platform has an architecture problem. There's nothing broken — it's just built wrong for its scale. The approach is yours to decide.
Four domains advance together. GraphQL, database performance, Docker Compose, and OpenTelemetry are new terrain. They're inseparable in practice — a multi-service application needs all of them — but each has its own concepts, tools, and AI failure modes. This is the largest single batch of AI-generated code you've directed so far. The gap between what exists in the project and what you personally understand — comprehension debt — becomes real here. Naming it helps: it's a structural phenomenon, not a personal failing.
AI generates GraphQL resolvers, Docker configs, and OpenTelemetry instrumentation quickly, but you'll spend proportionally more time understanding, verifying, and coordinating than in any previous project. Research consistently shows that AI shifts where the time goes rather than reducing total workload. If this project feels slower than the output volume suggests it should, that's the documented pattern — not a sign you're doing it wrong.
You govern AI tool access. Until now, MCP connections used whatever permissions were available. This project, you decide: should the database connection be read-only or read-write? Is that third-party MCP server trustworthy? Fewer connections with better permissions beats more connections with default access.
Tools
- Next.js, TypeScript, PostgreSQL, Prisma — continuing.
- Apollo Server / GraphQL — new. GraphQL server with resolvers and DataLoader.
- Redis — new. In-memory cache for API responses.
- Docker Compose — new. Multi-service local environment (app + database + cache).
- OpenTelemetry SDK — new. Distributed tracing, metrics, logs.
- Grafana — new. Observability dashboards.
- Azure App Service — new. First cloud deployment.
- Codex CLI — new. Second AI coding agent for MCP cross-platform verification.
- PostgreSQL MCP server — continuing.
- Sentry MCP server — new. Third-party MCP evaluation target.
- CLAUDE.md / AGENTS.md — continuing. You update these as the architecture evolves.
- VS Code + Claude Code, Git + GitHub — continuing.
Materials
- Working portfolio platform — a Next.js + PostgreSQL REST application with 210 project records. Functional but slow. The N+1 pattern is built into the API routes.
- Email from Elina — how the project starts. Precise, minimal, structured.
- Backlog notes — Elina's own list of the migration pieces (evaluation through deployment), kept as a reference; the units below sequence them.
- Project governance file — a starting CLAUDE.md you'll update as the architecture changes.