Backend & Data Architecture for a Multi-Platform Digital Product

Built and evolved the Node.js/TypeScript back end, Prisma/MySQL relational model, and APIs delivering shared domain data and multilingual content to multiple product clients.

Back-end · Data architectureBack-end, database & API ownershipAnonymized digital product

Context

The shared back end supported interconnected user and profile records, documents, geographic reference data, polling, and multilingual pages, navigation, and structured content for different product clients.

What had to be solved

This was not a collection of independent CRUD endpoints. Changes in one area could affect foreign-key relationships, existing production records, navigation and content behavior, and the data returned to different clients. The back end had to evolve without breaking those relationships while still returning content in the form each client required.

System boundaries

  • Production schema changes needed to be non-destructive and account for existing data.
  • Multilingual pages and hierarchical navigation had to support multiple navigation contexts and different client presentation requirements.

Back-end, database & API ownership

  • Owned the Node.js/TypeScript back end, Prisma/MySQL relational layer, APIs, and content/data architecture.
  • Designed the relationships and constraints linking user and profile data, addresses, education and experience, documents, polling and geography, and navigation and content records.
  • Implemented schema evolution and Prisma migrations, debugged migration state, and handled production-data and client-content delivery considerations.

System model

Product data flowWeb, mobile, and other product clients used shared back-end APIs over the same relational domain and content model.
Product clients
WebMobileContent surfaces
Back-end APIs · Content transformation
Domain services · Validation
Prisma · MySQL relational model
Cloud-hosted infrastructure

Where the complexity lived

  • Changing an interconnected production schema required sequencing foreign keys, indexes, unique constraints, and data changes so existing relationships remained valid.
  • Transforming stored HTML or content into ordered, structured representations suitable for mobile consumption where required.
  • Diagnosing schema drift and migration state without losing existing production data, while preserving safe backup and restore options for schema changes.

How the solution was structured

  • Kept the relational model explicit and enforced domain rules through constraints and service-level validation.
  • Separated stored content from client-specific representations while preserving order and semantic structure.
  • Planned migration order against existing data, verified database state before applying changes, and included backup and restore considerations in the rollout path.

What the work established

  • A working shared back end that delivered relational domain data and multilingual content to web, mobile, and other product surfaces without duplicating the core model for each client.

Technologies and systems

Node.jsTypeScriptPrismaMySQLAWS

The product name, hostnames, infrastructure addresses, credentials, secrets, proprietary business rules, and private schema or table names are omitted.