Arquitectura Backend & APIs
Tu producto se queda con un backend que aguanta crecer: servicios con límites claros, APIs documentadas y un modelo de datos pensado para las consultas que de verdad se ejecutan.
Esto suele empezar de dos maneras. O hay que levantar el backend de un producto nuevo y conviene no equivocarse con el modelo de datos ni con los contratos, o hay un backend que ya funciona pero cada cambio cuesta más que el anterior.
Los dos casos se atacan distinto. En un producto nuevo el foco está en poner cimientos que aguanten crecer; en uno que ya corre, en desmontar lo que frena al equipo sin parar la entrega.
Frentes de trabajo
Diseño de la API
Los contratos se acuerdan contigo antes de implementar. Cada endpoint tiene su esquema, sus códigos de error y su versión, así que tu equipo de cliente puede avanzar en paralelo contra ese contrato. Cuando la API la consumen varios equipos entran pruebas de contrato, para que un cambio no rompa a nadie en silencio.
Modelo de datos
El esquema es lo más caro de cambiar después, así que se le dedica tiempo al principio: claves, relaciones, qué se normaliza y qué no, y qué índices hacen falta para las consultas que de verdad se van a ejecutar. Las migraciones se escriben para poder desplegarse sin parar el servicio.
Trabajo en segundo plano
Todo lo que no tiene que responder en la petición se va a una cola: correos, webhooks, informes, sincronizaciones. Con reintentos, idempotencia y una dead letter queue que alguien mira, porque una cola sin observabilidad solo esconde los errores.
Frontend cuando hace falta
Muchos backends necesitan una consola interna o un panel para operar. Se construyen con React, Next.js o Angular, con el mismo criterio: estados de carga y de error de verdad, y nada de pantallas que solo funcionan con datos perfectos.
Cómo encaja
El camino de una petición
Lo que tiene que responder rápido y lo que se hace después, ya fuera de la petición.
Cliente
Web, móvil o una integración de terceros. Todos entran por la misma puerta.
Borde
Autenticación, permisos del tenant y rate limiting antes de tocar nada.
Servicio
Las reglas del negocio, separadas del framework y con sus propios tests.
PostgreSQL
Una transacción por operación, para que no queden escrituras a medias.
Lo que no se resuelve dentro de la petición
Cola (Celery / Sidekiq)Reintentos con backoffWebhook o notificación
Dónde poner el límite entre tenants
Es la decisión que más cuesta cambiar después. Depende de cuántos clientes hay y de cuánto aislamiento pide el contrato.
Columna tenant_id
- Una sola base y un solo juego de migraciones
- El aislamiento depende del código, así que se prueba en cada consulta
- Row level security cuando el dato es sensible
Sirve con muchos clientes pequeños y un equipo que puede sostener la disciplina.
Esquema por tenant
- Las tablas se repiten, la conexión elige el esquema
- Migrar es recorrer todos los esquemas, uno a uno
- Restaurar un solo cliente deja de ser un problema
Buen punto medio cuando son decenas de clientes y alguno pide sus datos aparte.
Base por tenant
- Aislamiento real, también en rendimiento
- Más piezas que operar: conexiones, backups, despliegues
- Cada cliente puede ir a su ritmo de versión
Se justifica con pocos clientes grandes o con requisitos de cumplimiento.
Qué incluye
- APIs REST y GraphQL con contratos versionados, documentados y con pruebas de contrato.
- Servicios en Python (Django, FastAPI), Node (NestJS, Express), Deno o Ruby on Rails, según lo que ya corra tu equipo.
- Modelo de datos en PostgreSQL: esquema, índices, migraciones y consultas que no se degraden al crecer la tabla.
- Trabajo asíncrono con colas (Celery, Sidekiq, BullMQ) para lo que no debe bloquear una petición.
- Autenticación y autorización: sesiones, JWT, OAuth, roles y permisos, y separación por tenant cuando hay varios clientes.
- Caché con Redis donde de verdad hace falta, con invalidación pensada antes de escribirla.
- Pruebas de los caminos críticos con pytest, RSpec o Jest, y datos de prueba que no dependan de producción.
- Observabilidad desde el primer día: logs con contexto, métricas y trazas distribuidas.
Cómo avanza el proyecto
- 01Antes de proponer nada se revisa lo que ya existe y se habla con quien lo mantiene.
- 02Los contratos de API y el modelo de datos se acuerdan contigo antes de escribir la implementación.
- 03La entrega va en incrementos que se pueden desplegar, así que hay algo funcionando desde la primera semana.
- 04Al terminar quedan pruebas de los caminos críticos y documentación de cómo se opera.
Qué te llevas
- Servicios en producción, con su pipeline de despliegue.
- Documentación de las APIs y del modelo de datos.
- Suite de pruebas de los caminos críticos.
- Guía de operación: qué mirar cuando algo falla.
Stack habitual
- Python
- DjangoDjango REST FrameworkFastAPICelerySQLAlchemypytest
- Ruby on Rails
- ActiveRecordActiveJobSidekiqDeviseCanCanCanRSpecSorbet
- JavaScript / TypeScript
- NestJSExpressDenoNode.jsPrismaJest
- APIs
- RESTGraphQLOpenAPIJSON SchemaWebhooks
- Datos
- PostgreSQLRedisMongoDBS3
- Frontend
- ReactNext.jsAngularTypeScript
Dónde se ha hecho esto
Preguntas frecuentes
¿Se puede trabajar sobre un backend que ya está en producción?
Sí, y es el caso más habitual. El trabajo entra por incrementos que se despliegan solos: primero se acota una parte del sistema, se le ponen pruebas y se cambia con la entrega en marcha. Nadie tiene que congelar el producto durante semanas para que esto avance.
¿Qué pasa con el equipo que ya mantiene el código?
Sigue siendo el dueño del código. Las decisiones de contrato y de modelo de datos se acuerdan con ellos, y al terminar quedan las pruebas y la documentación de operación para que puedan seguir sin depender de nadie de fuera.
¿En qué lenguaje conviene construirlo?
En el que tu equipo pueda mantener. Python con Django o FastAPI, Ruby on Rails y Node con NestJS o Express cubren prácticamente el mismo terreno; la elección la decide qué sabe operar el equipo y qué hay ya en marcha, no la moda del año.
¿Cómo se sabe si el backend aguantará crecer?
Por el modelo de datos y por los límites entre servicios, que es lo más caro de cambiar después. Las consultas se revisan contra el volumen esperado, no contra la base de desarrollo, y lo que no tiene que responder dentro de la petición se va a una cola desde el principio.