Backend

Backend, también escrito back-end y denominado en español desarrollo del lado del servidor, es la parte de una aplicación, sitio web o sistema digital encargada de recibir solicitudes, ejecutar reglas de negocio, autenticar usuarios, procesar información, comunicarse con bases de datos, integrar servicios y devolver resultados al frontend o a otros sistemas.

El backend comprende el código, los servicios, las bases de datos, las API, los servidores, las colas de mensajes, los sistemas de almacenamiento, los controles de seguridad y la infraestructura que permiten que una aplicación funcione más allá de su interfaz visible. Aunque el usuario normalmente no observa directamente esta capa, sus operaciones determinan la disponibilidad, exactitud, velocidad, privacidad, seguridad y continuidad del servicio.

En marketing digital, el backend administra procesos como el registro de prospectos, la integración con un CRM, la personalización de contenidos, el procesamiento de pedidos, la atribución de conversiones, la automatización de comunicaciones, el almacenamiento de eventos, la administración de catálogos y la conexión entre sitios, plataformas publicitarias y sistemas comerciales.

Introducción

Las aplicaciones digitales suelen organizarse mediante una separación entre la capa que interactúa directamente con las personas y la capa que procesa las operaciones internas. El frontend presenta botones, formularios, contenidos, menús y resultados, mientras el backend interpreta las solicitudes, aplica reglas y obtiene o modifica información.

Cuando una persona inicia sesión, el frontend recopila sus credenciales y las envía al backend. El backend localiza la cuenta, verifica la contraseña, analiza restricciones de acceso, genera una sesión y devuelve una respuesta. La interfaz muestra entonces la información permitida para ese usuario.

En una tienda en línea, el backend puede encargarse de:

almacenar productos;
consultar existencias;
calcular precios;
aplicar descuentos;
validar cupones;
procesar pedidos;
registrar pagos;
actualizar inventarios;
generar notificaciones;
comunicar información a sistemas logísticos.

En un sitio de generación de leads, el backend recibe los datos del formulario, elimina entradas inválidas, identifica duplicados, registra el origen de la campaña, crea un contacto en el CRM, asigna un vendedor y activa una secuencia de seguimiento.

En una plataforma de contenidos, administra usuarios, permisos, artículos, categorías, comentarios, búsquedas, versiones, archivos y procesos editoriales.

MDN describe la programación del lado del servidor como el conjunto de operaciones que permiten generar respuestas personalizadas ante solicitudes HTTP, acceder a bases de datos, validar datos y controlar qué información se entrega a cada usuario.

El backend no necesariamente se encuentra dentro de un único servidor físico. Una aplicación puede distribuir sus componentes entre varios proveedores, centros de datos, contenedores, funciones sin servidor, servicios administrados y redes de distribución.

El término tampoco se limita al desarrollo web. Una aplicación móvil, un dispositivo conectado, un videojuego, una plataforma de voz y un sistema empresarial pueden utilizar servicios backend para almacenar datos, coordinar usuarios, aplicar reglas y sincronizar operaciones.

La calidad de un backend afecta directamente la experiencia visible. Una interfaz bien diseñada puede resultar inútil si las solicitudes tardan demasiado, los datos son incorrectos, las sesiones fallan o el sistema pierde operaciones.

Definición

Backend puede definirse como la capa de software e infraestructura que ejecuta las funciones internas de una aplicación y proporciona datos o servicios a clientes mediante interfaces controladas.

Una definición operativa puede apoyarse en diez criterios:

Procesamiento del lado del servidor: una parte fundamental de las operaciones ocurre fuera del dispositivo del usuario.

Aplicación de reglas de negocio: el sistema decide cómo deben procesarse pedidos, permisos, cálculos y estados.

Administración de datos: crea, consulta, modifica, relaciona y elimina información.

Exposición de servicios: proporciona funciones mediante API, protocolos, eventos o mensajes.

Autenticación y autorización: verifica identidades y controla acciones permitidas.

Integración: se comunica con pagos, CRM, correo, almacenamiento, analítica y otros sistemas.

Persistencia: conserva información más allá de una sesión individual.

Seguridad: protege datos, operaciones, credenciales y servicios.

Escalabilidad: adapta la capacidad ante cambios de tráfico y volumen.

Observabilidad: registra eventos, errores, métricas y trazas para comprender su funcionamiento.

El backend puede responder directamente con HTML, entregar datos estructurados como JSON, procesar eventos sin interfaz visible o ejecutar tareas programadas.

Una aplicación pequeña puede reunir todo el backend dentro de un único programa y una base de datos. Un sistema amplio puede utilizar cientos de servicios independientes distribuidos entre varias regiones.

Terminología

Backend. Forma unida ampliamente utilizada dentro de la industria.

Back-end. Variante con guion frecuente en inglés técnico.

Back end. Forma separada utilizada como sustantivo en inglés.

Desarrollo backend. Actividad dedicada a construir la lógica, los servicios y la infraestructura interna de una aplicación.

Desarrollo del lado del servidor. Expresión que enfatiza que el código se ejecuta principalmente en servidores.

Server-side programming. Denominación inglesa empleada en documentación técnica.

Capa de aplicación. Parte encargada de coordinar reglas y casos de uso.

Capa de negocio. Contiene decisiones relacionadas con procesos y políticas de una organización.

Servidor de aplicaciones. Entorno que ejecuta la lógica de una aplicación.

Servicio backend. Componente que proporciona funciones o datos a clientes.

Backend as a Service. Plataforma que ofrece autenticación, datos, almacenamiento y funciones administradas.

Backend for Frontend. Patrón que crea una capa backend específica para una interfaz o tipo de cliente.

El término servidor puede referirse tanto a un programa que atiende solicitudes como a la máquina física o virtual donde ese programa se ejecuta.

Una base de datos forma parte frecuente del backend, aunque no constituye por sí misma todo el backend. El sistema también necesita lógica, interfaces, seguridad y coordinación.

Contexto histórico y evolución

La historia del backend está vinculada con la evolución de los sistemas informáticos, las redes, las bases de datos y la Web.

Sistemas centralizados

Las primeras aplicaciones empresariales se ejecutaban en grandes computadoras centrales. Los terminales enviaban instrucciones y mostraban resultados, mientras el procesamiento y almacenamiento permanecían dentro del sistema central.

Este modelo estableció una separación temprana entre terminales de interacción y recursos centrales.

Arquitectura cliente-servidor

La expansión de redes y computadoras personales popularizó la arquitectura cliente-servidor.

El cliente proporcionaba la interfaz y solicitaba operaciones. El servidor administraba datos, archivos, impresión, autenticación u otros recursos compartidos.

Este enfoque permitió que múltiples usuarios utilizaran un sistema central sin almacenar toda la lógica y la información en cada equipo.

Bases de datos relacionales

Los sistemas de gestión de bases de datos relacionales permitieron organizar información en tablas relacionadas y consultarla mediante SQL.

La separación entre aplicación y base de datos facilitó centralizar información, controlar concurrencia, aplicar restricciones y conservar transacciones.

Aplicaciones de dos y tres capas

Las aplicaciones cliente-servidor iniciales podían conectar directamente la interfaz con la base de datos.

Las arquitecturas de tres capas separaron:

presentación;
lógica de negocio;
almacenamiento.

Esta separación redujo el acceso directo desde los clientes hacia las bases de datos y permitió centralizar reglas, seguridad y procesos.

Aparición de la Web

Los primeros sitios web utilizaban servidores que entregaban archivos HTML estáticos. Cada URL correspondía normalmente con un documento almacenado.

La necesidad de personalizar contenido produjo tecnologías como CGI, que permitían ejecutar programas para generar respuestas dinámicas.

Los lenguajes del lado del servidor comenzaron a utilizarse para procesar formularios, administrar sesiones y consultar bases de datos.

Lenguajes y plataformas web

Durante la década de 1990 y los primeros años del siglo XXI se difundieron tecnologías como:

Perl;
PHP;
Java;
ASP;
ColdFusion;
Python;
Ruby.

Estas herramientas permitieron construir tiendas, portales, buscadores, foros, gestores de contenido y sistemas empresariales.

Frameworks backend

Los frameworks organizaron tareas frecuentes como:

enrutamiento;
formularios;
plantillas;
sesiones;
autenticación;
consultas;
migraciones;
seguridad.

Ruby on Rails popularizó el principio de convención sobre configuración y el desarrollo rápido de aplicaciones.

Django promovió una estructura integral para aplicaciones Python. Spring se convirtió en un ecosistema importante para sistemas Java. Laravel simplificó el desarrollo con PHP y ASP.NET evolucionó dentro del ecosistema de Microsoft.

Ajax y API

La expansión de Ajax permitió que las páginas solicitaran datos al servidor sin recargarse por completo.

El backend comenzó a entregar información estructurada mediante XML y posteriormente JSON.

Las API se convirtieron en una capa central que podía atender sitios, aplicaciones móviles, integraciones y servicios externos.

Arquitectura orientada a servicios

Las organizaciones dividieron funciones empresariales en servicios conectados mediante contratos y protocolos.

La arquitectura orientada a servicios permitió reutilizar operaciones entre diferentes aplicaciones, aunque podía introducir infraestructura compleja y procesos centralizados.

Computación en la nube

La computación en la nube facilitó alquilar servidores, almacenamiento, redes y bases de datos mediante interfaces administradas.

Las organizaciones podían aumentar capacidad sin adquirir directamente todo el hardware.

Los servicios administrados redujeron trabajo relacionado con instalación, actualización, redundancia y respaldo.

Contenedores

Los contenedores empaquetaron aplicaciones junto con dependencias y configuraciones necesarias para ejecutarlas de manera consistente.

Docker popularizó este modelo y Kubernetes se convirtió en una plataforma para administrar cargas de trabajo contenerizadas, servicios, despliegues y escalamiento.

Microservicios

La arquitectura de microservicios divide una aplicación en servicios pequeños, desplegables y administrables de manera relativamente independiente.

Este enfoque puede facilitar autonomía y escalamiento selectivo, aunque aumenta la complejidad de red, datos, observabilidad, seguridad y coordinación.

Serverless

La computación sin servidor permite ejecutar funciones y servicios sin administrar directamente las máquinas subyacentes.

El proveedor se encarga de capacidad, mantenimiento y parte del escalamiento. El usuario paga generalmente por uso o ejecución.

Serverless no significa ausencia de servidores. Los servidores existen, pero son administrados por la plataforma.

API-first y headless

Los sistemas headless separan el backend de una interfaz específica.

Un mismo backend puede proporcionar contenidos, productos y operaciones a:

sitios;
aplicaciones móviles;
dispositivos;
asistentes;
tiendas;
integraciones.

El enfoque API-first diseña los contratos de comunicación antes o junto con las interfaces y servicios.

Backend contemporáneo

El backend actual puede combinar:

servicios web;
bases de datos;
cachés;
colas;
contenedores;
funciones;
API;
almacenamiento de objetos;
búsquedas;
flujos de datos;
inteligencia artificial;
observabilidad;
despliegues automáticos.

El desarrollo asistido por IA y los agentes de programación aceleran la creación de servicios, aunque aumentan la necesidad de revisar arquitectura, seguridad y mantenimiento.

Fundamentos teóricos

Modelo cliente-servidor. Un cliente solicita recursos y un servidor procesa la petición y produce una respuesta.

Separación de responsabilidades. Las funciones se dividen para evitar que una sola parte concentre presentación, lógica, persistencia e infraestructura.

Abstracción. Las capas ocultan detalles internos y proporcionan interfaces comprensibles.

Encapsulación. Cada componente controla su información y comportamiento.

Modularidad. El sistema se divide en unidades que pueden desarrollarse y probarse separadamente.

Acoplamiento. Describe cuánto depende un componente de otro.

Cohesión. Mide qué tan relacionadas se encuentran las responsabilidades dentro de un módulo.

Contratos. Las API establecen entradas, salidas, errores y comportamientos esperados.

Persistencia. Los datos se conservan después de terminar una ejecución.

Consistencia. El sistema mantiene reglas válidas entre datos y operaciones.

Transacción. Agrupa operaciones que deben completarse o revertirse como una unidad.

Concurrencia. Varias solicitudes y procesos pueden operar simultáneamente.

Idempotencia. Una operación repetida produce un efecto equivalente al de ejecutarla una sola vez.

Tolerancia a fallos. El sistema continúa funcionando o se recupera cuando un componente falla.

Escalabilidad. La capacidad puede aumentar conforme crecen usuarios, tráfico y datos.

Disponibilidad. El servicio permanece accesible durante el tiempo esperado.

Durabilidad. Los datos confirmados sobreviven a errores y reinicios.

Consistencia eventual. Diferentes copias pueden presentar temporalmente valores distintos y converger después.

Principio de mínimo privilegio. Cada usuario y servicio recibe únicamente los permisos necesarios.

Defensa en profundidad. La seguridad se distribuye entre varias capas y controles.

Observabilidad. El estado interno puede inferirse mediante registros, métricas y trazas.

Modelo cliente-servidor

La interacción típica comienza cuando un cliente envía una solicitud.

El cliente puede ser:

navegador;
aplicación móvil;
otro servidor;
dispositivo;
sistema empresarial;
agente automatizado;
línea de comandos.

El backend recibe la solicitud y puede ejecutar la siguiente secuencia:

aceptar la conexión;

interpretar el protocolo;

identificar la ruta;

verificar autenticación;

validar datos;

aplicar autorización;

ejecutar lógica;

consultar servicios o bases de datos;

construir una respuesta;

registrar el resultado;

devolver información al cliente.

Una respuesta HTTP contiene un código que comunica el resultado general.

Ejemplos frecuentes:

`200 OK`;
`201 Created`;
`204 No Content`;
`400 Bad Request`;
`401 Unauthorized`;
`403 Forbidden`;
`404 Not Found`;
`409 Conflict`;
`422 Unprocessable Content`;
`429 Too Many Requests`;
`500 Internal Server Error`;
`503 Service Unavailable`.

Los códigos deben utilizarse de forma consistente para que clientes, herramientas y operadores comprendan el estado de cada operación.

Ciclo de una solicitud

Una solicitud web puede atravesar varias capas antes de producir una respuesta.

1. Resolución DNS. El dominio se relaciona con una dirección o servicio.

2. Conexión. El cliente establece comunicación mediante TCP, QUIC u otro transporte.

3. Cifrado. HTTPS negocia una conexión protegida mediante TLS.

4. Proxy o balanceador. La solicitud puede distribuirse entre varios servidores.

5. Servidor web. Recibe HTTP y sirve archivos o reenvía la petición.

6. Middleware. Procesa autenticación, registros, límites, compresión y otras funciones compartidas.

7. Enrutador. Selecciona el controlador correspondiente con la URL y el método.

8. Controlador. Interpreta parámetros y coordina el caso de uso.

9. Servicio de dominio. Ejecuta reglas y operaciones.

10. Repositorio. Consulta o modifica información persistente.

11. Integraciones. Contacta servicios externos cuando resulta necesario.

12. Serialización. Convierte el resultado a HTML, JSON, XML u otro formato.

13. Respuesta. Devuelve código, encabezados y cuerpo.

14. Observabilidad. Registra tiempos, errores, identificadores y efectos.

Una arquitectura concreta puede combinar, omitir o reorganizar estas etapas.

Componentes principales

Servidor web. Recibe solicitudes HTTP y entrega respuestas o archivos.

Servidor de aplicaciones. Ejecuta la lógica del sistema.

Router. Relaciona rutas y métodos con funciones.

Middleware. Añade comportamiento compartido durante solicitudes y respuestas.

Controlador. Coordina una operación concreta.

Servicio. Implementa casos de uso o funciones de negocio.

Modelo de dominio. Representa entidades, reglas y relaciones del problema.

Repositorio. Abstrae el acceso a datos.

Base de datos. Conserva información estructurada o semiestructurada.

Caché. Almacena resultados temporales para reducir latencia.

Cola de mensajes. Permite procesar tareas de manera asíncrona.

Bus de eventos. Distribuye acontecimientos hacia consumidores.

Almacenamiento de objetos. Conserva imágenes, videos, documentos y respaldos.

Motor de búsqueda. Proporciona búsquedas de texto, filtros y relevancia.

API. Expone funciones y datos mediante contratos.

Autenticación. Comprueba la identidad.

Autorización. Controla permisos.

Planificador. Ejecuta tareas en horarios o intervalos.

Worker. Procesa trabajos fuera del flujo principal.

Proxy inverso. Recibe solicitudes y las reenvía hacia servicios internos.

Balanceador de carga. Distribuye tráfico.

Gestor de secretos. Protege credenciales y claves.

Sistema de observabilidad. Reúne registros, métricas y trazas.

Arquitectura por capas

Una arquitectura backend puede organizarse en capas.

Capa de presentación o transporte

Recibe solicitudes mediante HTTP, mensajes, comandos o eventos.

Se encarga de:

rutas;
formatos;
validación básica;
códigos de respuesta;
serialización.

Capa de aplicación

Coordina casos de uso como:

registrar cliente;
completar compra;
emitir factura;
publicar contenido;
enviar campaña.

La capa de aplicación organiza operaciones sin concentrar necesariamente todas las reglas de negocio.

Capa de dominio

Representa entidades, valores, políticas y reglas propias del negocio.

Ejemplos:

un pedido no puede enviarse antes de pagarse;
una promoción tiene vigencia;
un usuario posee un límite;
una comisión se calcula bajo determinadas condiciones.

Capa de infraestructura

Implementa acceso a bases de datos, correo, almacenamiento, pagos, colas y servicios externos.

La separación permite sustituir tecnologías con menor impacto sobre las reglas centrales.

Lógica de negocio

La lógica de negocio representa las reglas que distinguen una aplicación de un simple almacenamiento de datos.

Puede incluir:

cálculos;
validaciones;
políticas;
estados;
autorizaciones;
límites;
prioridades;
comisiones;
precios;
promociones;
segmentaciones;
asignaciones.

Una tienda puede contener reglas para:

calcular impuestos;
verificar inventario;
reservar existencias;
aplicar descuentos;
seleccionar entrega;
registrar pagos;
autorizar devoluciones.

La lógica crítica debe implementarse en el backend porque el código frontend puede ser modificado o evitado por el usuario.

La duplicación de reglas entre varias interfaces puede producir resultados contradictorios. Conviene centralizar las decisiones importantes o compartir contratos y validaciones.

Servidores web y servidores de aplicaciones

Un servidor web atiende solicitudes HTTP y puede servir archivos estáticos como HTML, CSS, JavaScript e imágenes.

También puede funcionar como proxy inverso y enviar solicitudes dinámicas a un servidor de aplicaciones.

Entre los servidores web conocidos se encuentran:

Nginx;
Apache HTTP Server;
Caddy;
Microsoft IIS.

Un servidor de aplicaciones ejecuta código relacionado con lógica, sesiones, datos e integraciones.

La separación exacta varía. Algunos frameworks incluyen su propio servidor HTTP y algunas plataformas integran servidor web, ejecución y despliegue dentro del mismo entorno.

En producción pueden utilizarse proxies especializados para TLS, compresión, límites, caché y distribución.

Bases de datos

Las bases de datos permiten conservar y consultar información.

Bases de datos relacionales

Organizan datos en tablas con filas, columnas, relaciones y restricciones.

Utilizan frecuentemente SQL.

Ejemplos:

PostgreSQL;
MySQL;
MariaDB;
Microsoft SQL Server;
Oracle Database;
SQLite.

Las bases relacionales resultan adecuadas para datos con estructura, relaciones y transacciones.

Bases de datos documentales

Almacenan documentos, generalmente con estructuras semejantes a JSON.

Ejemplos:

MongoDB;
CouchDB;
Firestore.

Pueden facilitar esquemas flexibles y agrupación de información relacionada dentro de un documento.

Bases clave-valor

Relacionan una clave con un valor.

Ejemplos:

Redis;
DynamoDB en determinados usos;
etcd.

Se utilizan en caché, sesiones, contadores, configuraciones y datos de acceso rápido.

Bases columnares

Organizan o procesan datos por columnas y resultan útiles en analítica y grandes agregaciones.

Bases de grafos

Representan nodos y relaciones.

Pueden utilizarse en redes, recomendaciones, fraude, conocimiento y rutas.

Bases de series temporales

Se especializan en datos relacionados con tiempo, como métricas, sensores y eventos.

Motores de búsqueda

Sistemas como Elasticsearch y OpenSearch crean índices para búsquedas, filtros y análisis de texto.

No siempre sustituyen la base de datos principal. Frecuentemente mantienen una copia optimizada para consulta.

Modelado de datos

El modelado define qué información existe y cómo se relaciona.

Puede incluir:

entidades;
atributos;
identificadores;
relaciones;
restricciones;
índices;
estados;
historial;
propiedad;
permisos.

Un sistema comercial puede contener:

clientes;
empresas;
oportunidades;
productos;
pedidos;
actividades;
vendedores;
campañas.

Las decisiones de modelado afectan rendimiento, integridad y facilidad de evolución.

Normalización

La normalización reduce duplicación y organiza relaciones dentro de tablas.

Desnormalización

La desnormalización duplica determinados datos para acelerar lecturas o simplificar consultas.

Esquema

El esquema describe tablas, campos, tipos, relaciones y restricciones.

Las bases con esquema flexible también necesitan convenciones y validaciones para evitar estructuras incompatibles.

Migraciones

Las migraciones modifican la estructura de datos mediante cambios versionados.

Deben diseñarse para evitar pérdidas, bloqueos prolongados y incompatibilidades entre versiones.

Transacciones

Una transacción agrupa operaciones que deben conservar coherencia.

Las propiedades ACID se expresan como:

Atomicidad. Todas las operaciones se completan o ninguna se aplica.

Consistencia. La transacción mantiene las reglas válidas de la base.

Aislamiento. Las operaciones concurrentes no producen efectos indebidos entre sí.

Durabilidad. Los cambios confirmados sobreviven a fallos.

Una compra puede necesitar una transacción que registre pedido, pago e inventario de forma coordinada.

Las transacciones distribuidas entre varios servicios resultan más complejas. Pueden utilizarse eventos, compensaciones, sagas e idempotencia.

Caché

La caché conserva temporalmente datos o resultados utilizados con frecuencia.

Puede ubicarse en:

navegador;
CDN;
proxy;
servidor;
memoria;
base especializada.

La caché puede reducir:

tiempo de respuesta;
carga de base de datos;
consumo de red;
costos.

Los patrones incluyen:

Cache-aside. La aplicación busca primero en caché y consulta la fuente cuando no encuentra el dato.

Write-through. La escritura actualiza caché y almacenamiento.

Write-behind. La caché confirma inicialmente y persiste después.

Read-through. El sistema de caché obtiene automáticamente la información faltante.

La invalidación representa uno de los problemas principales. Un dato almacenado puede quedar obsoleto cuando cambia su fuente.

Las estrategias incluyen:

tiempo de expiración;
eliminación explícita;
versiones;
eventos;
claves jerárquicas.

API

Una API define cómo pueden comunicarse aplicaciones y servicios.

El backend puede exponer operaciones para:

consultar productos;
crear pedidos;
autenticar usuarios;
actualizar contactos;
subir archivos;
registrar eventos;
ejecutar búsquedas.

Una API debe especificar:

rutas;
métodos;
parámetros;
formatos;
permisos;
errores;
límites;
versiones.

REST

REST es un estilo arquitectónico basado en recursos, representaciones e interfaces uniformes.

Las API REST utilizan frecuentemente métodos HTTP como:

GET;
POST;
PUT;
PATCH;
DELETE.

Una API REST no se define solamente por utilizar JSON y HTTP. También considera principios como ausencia de estado entre solicitudes, separación cliente-servidor y recursos identificables.

GraphQL

GraphQL es un lenguaje de consulta para API y un entorno de ejecución del lado del servidor basado en un esquema tipado.

Permite que el cliente solicite campos específicos.

Sus operaciones principales son:

query;
mutation;
subscription.

GraphQL ofrece flexibilidad y herramientas de introspección, aunque necesita controles sobre complejidad, autorización, caché y consumo.

RPC

La llamada a procedimiento remoto representa operaciones como funciones que pueden invocarse a través de una red.

gRPC utiliza contratos y Protocol Buffers para comunicación eficiente entre servicios.

Webhooks

Un webhook envía una solicitud cuando ocurre un evento.

Ejemplos:

pago confirmado;
formulario recibido;
pedido enviado;
suscripción cancelada.

Los webhooks necesitan firmas, reintentos, idempotencia y registros.

WebSocket

WebSocket permite comunicación bidireccional persistente entre cliente y servidor.

Se utiliza en chats, juegos, paneles y actualizaciones en tiempo real.

Server-Sent Events

Permite que el servidor envíe una secuencia de eventos al navegador mediante una conexión HTTP.

Autenticación

La autenticación determina quién intenta acceder.

Los mecanismos incluyen:

usuario y contraseña;
enlaces de acceso;
códigos temporales;
autenticación multifactor;
biometría;
proveedores externos;
certificados;
claves de API.

Las contraseñas deben almacenarse mediante funciones de derivación diseñadas para este propósito y nunca como texto simple.

El backend debe aplicar:

límites de intentos;
recuperación segura;
revocación;
protección de sesiones;
registros;
alertas.

Autorización

La autorización determina qué puede hacer una identidad autenticada.

Los modelos incluyen:

RBAC. Los permisos se asignan mediante roles.

ABAC. Las decisiones utilizan atributos del usuario, recurso y contexto.

ACL. Cada recurso contiene una lista de accesos.

Permisos por capacidad. El acceso se concede mediante tokens o referencias específicas.

Las comprobaciones deben realizarse en el backend para cada operación sensible.

Ocultar elementos en el frontend no impide que una persona envíe solicitudes directas.

OWASP identifica la autorización incorrecta sobre objetos como uno de los riesgos principales en API.

Sesiones y tokens

Una sesión puede conservarse mediante un identificador enviado al cliente y datos almacenados en el servidor.

Los tokens pueden contener información firmada y verificable.

Cookies

Las cookies pueden utilizar atributos como:

Secure;
HttpOnly;
SameSite;
Domain;
Path;
Max-Age.

JSON Web Token

JSON Web Token define un formato compacto para transmitir claims firmados o protegidos.

Un JWT no se encuentra cifrado por defecto y su contenido puede ser legible.

Los sistemas deben verificar:

firma;
emisor;
audiencia;
expiración;
algoritmo;
revocación cuando corresponda.

Los tokens de larga duración aumentan el impacto de una filtración.

OAuth

OAuth permite delegar acceso a recursos sin compartir directamente las credenciales del usuario con cada aplicación.

OAuth se relaciona con autorización y no sustituye por sí mismo un sistema completo de identidad.

OpenID Connect añade una capa de autenticación sobre OAuth 2.0.

Colas y procesamiento asíncrono

Las tareas lentas o independientes pueden procesarse fuera de la solicitud principal.

Ejemplos:

enviar correos;
generar archivos;
convertir videos;
procesar imágenes;
sincronizar inventarios;
importar datos;
calcular reportes.

El backend publica un mensaje y un worker lo procesa.

Las plataformas incluyen:

RabbitMQ;
Apache Kafka;
Amazon SQS;
Google Pub/Sub;
Azure Service Bus;
Redis Streams.

Los sistemas deben considerar:

reintentos;
duplicados;
orden;
confirmaciones;
colas de errores;
visibilidad;
idempotencia.

Una tarea puede ejecutarse más de una vez debido a reintentos, por lo que debe diseñarse para evitar efectos duplicados.

Arquitectura orientada a eventos

En una arquitectura orientada a eventos, los componentes reaccionan ante acontecimientos.

Ejemplos:

`LeadCreado`;
`PagoConfirmado`;
`PedidoEnviado`;
`UsuarioRegistrado`;
`ContenidoPublicado`.

Los productores publican eventos y los consumidores ejecutan acciones.

Ventajas:

desacoplamiento;
procesamiento asíncrono;
extensibilidad;
integración.

Limitaciones:

rastreo complejo;
consistencia eventual;
duplicados;
orden;
evolución de esquemas;
depuración distribuida.

Los eventos deben describir hechos ocurridos y no convertirse en comandos ambiguos ocultos.

Almacenamiento de archivos

Las aplicaciones pueden almacenar:

imágenes;
videos;
documentos;
respaldos;
exportaciones;
archivos temporales.

El almacenamiento de objetos permite conservar archivos mediante claves y metadatos.

Los archivos grandes suelen cargarse directamente hacia servicios de almacenamiento mediante URLs firmadas, en lugar de atravesar por completo el servidor de aplicación.

Las medidas de seguridad incluyen:

validación de tipo;
límites de tamaño;
nombres generados;
análisis de malware;
permisos;
aislamiento;
expiración;
eliminación.

La extensión proporcionada por el usuario no demuestra el tipo real del archivo.

Arquitecturas backend

Monolito

Un monolito reúne numerosas funciones dentro de una sola aplicación desplegable.

Ventajas:

desarrollo inicial sencillo;
transacciones directas;
depuración centralizada;
menor complejidad operativa.

Limitaciones:

acoplamiento creciente;
despliegues amplios;
escalamiento conjunto;
dificultad para separar equipos.

Un monolito bien organizado puede sostener sistemas grandes. La palabra no implica necesariamente una arquitectura deficiente.

Monolito modular

Mantiene una sola unidad de despliegue y separa internamente dominios y módulos.

Puede proporcionar simplicidad operativa con límites arquitectónicos claros.

Microservicios

Dividen el sistema en servicios independientes.

Ventajas potenciales:

despliegue separado;
autonomía de equipos;
escalamiento selectivo;
aislamiento parcial.

Limitaciones:

comunicación de red;
observabilidad;
consistencia;
despliegue;
seguridad;
costos;
coordinación.

Los microservicios no deben adoptarse únicamente por popularidad. Una organización pequeña puede obtener mejores resultados con un monolito modular.

Arquitectura serverless

Utiliza funciones y servicios administrados activados mediante solicitudes o eventos.

Ventajas:

menor gestión de servidores;
escalamiento automático;
pago por uso;
integración con eventos.

Limitaciones:

latencia inicial;
límites de ejecución;
observabilidad;
dependencia del proveedor;
costos variables;
pruebas locales.

Backend for Frontend

El patrón Backend for Frontend crea un backend adaptado a una experiencia específica.

Puede existir un BFF para:

sitio web;
aplicación móvil;
panel interno;
dispositivo.

Cada BFF reúne y transforma información según las necesidades de su cliente.

Arquitectura headless

El backend proporciona contenidos y funciones mediante API sin controlar directamente la capa de presentación.

Se utiliza en:

CMS headless;
comercio electrónico;
plataformas multicanal;
aplicaciones móviles.

Arquitectura hexagonal

Separa el dominio de sus mecanismos externos mediante puertos y adaptadores.

La base de datos, las API y las interfaces se consideran adaptadores sustituibles.

Clean Architecture

Organiza dependencias para que las reglas centrales no dependan de frameworks ni infraestructura.

CQRS

CQRS separa operaciones de lectura y escritura.

Puede resultar útil cuando ambos flujos poseen necesidades diferentes, aunque aumenta complejidad.

Event sourcing

Conserva la secuencia de eventos que produjo el estado, en lugar de almacenar únicamente el valor final.

Facilita auditoría y reconstrucción, pero exige diseño especializado.

Lenguajes backend

JavaScript y TypeScript

Node.js permite ejecutar JavaScript fuera del navegador y construir servidores, herramientas y aplicaciones web.

Frameworks y bibliotecas incluyen:

Express;
Fastify;
NestJS;
Koa;
Hapi.

TypeScript añade análisis estático y contratos de tipos.

Python

Python se utiliza en aplicaciones web, automatización, datos e inteligencia artificial.

Frameworks:

Django;
Flask;
FastAPI;
Pyramid.

Django proporciona un ecosistema integral. Flask ofrece una base ligera y FastAPI se orienta a API con tipado y documentación automática.

PHP

PHP se utiliza ampliamente en sitios, sistemas de contenidos y comercio electrónico.

Frameworks:

Laravel;
Symfony;
CodeIgniter.

Plataformas como WordPress, Drupal y WooCommerce utilizan PHP.

Java

Java se utiliza en sistemas empresariales, financieros y distribuidos.

Spring Boot facilita construir servicios y aplicaciones dentro del ecosistema Spring.

Otros frameworks incluyen Jakarta EE, Quarkus y Micronaut.

C#

C# y ASP.NET Core se utilizan para API, aplicaciones web, servicios empresariales y sistemas integrados con Microsoft.

Ruby

Ruby on Rails promueve convención sobre configuración y proporciona herramientas integradas para aplicaciones web.

Go

Go se utiliza en servicios de red, sistemas distribuidos, plataformas de nube y herramientas de infraestructura.

Frameworks y routers incluyen Gin, Echo, Fiber y Chi.

Rust

Rust se orienta a seguridad de memoria y rendimiento.

Frameworks backend incluyen Axum, Actix Web y Rocket.

Kotlin

Kotlin se utiliza en JVM y aplicaciones multiplataforma. Puede emplearse con Spring, Ktor y otros frameworks.

Elixir

Elixir y Phoenix utilizan la máquina virtual de Erlang y se orientan a sistemas concurrentes, distribuidos y en tiempo real.

La selección del lenguaje debe considerar:

experiencia del equipo;
ecosistema;
rendimiento;
seguridad;
mantenimiento;
disponibilidad de profesionales;
integración;
vida útil.

Frameworks backend

Un framework proporciona componentes reutilizables para tareas frecuentes.

Puede incluir:

rutas;
middleware;
validación;
autenticación;
sesiones;
acceso a datos;
plantillas;
pruebas;
seguridad;
configuración.

MDN señala que los frameworks del lado del servidor facilitan escribir, mantener y escalar aplicaciones, además de proporcionar herramientas para rutas, bases de datos, sesiones, autorización y formatos de salida.

Un framework reduce trabajo repetitivo y también introduce convenciones, dependencias y ciclos de actualización.

La selección debe evaluar:

documentación;
comunidad;
estabilidad;
seguridad;
rendimiento;
compatibilidad;
mantenimiento.

Desarrollo backend

Un proceso de desarrollo puede seguir estas etapas:

1. Definición del problema. Se establece qué necesidad debe resolverse.

2. Identificación de usuarios y sistemas. Se determina quién utilizará el servicio.

3. Requisitos funcionales. Se describen operaciones y reglas.

4. Requisitos no funcionales. Se establecen seguridad, rendimiento, disponibilidad y cumplimiento.

5. Modelado de dominio. Se identifican entidades, estados y políticas.

6. Diseño de datos. Se definen estructuras, relaciones e índices.

7. Diseño de API. Se especifican contratos, errores y permisos.

8. Selección tecnológica. Se eligen lenguaje, framework, almacenamiento e infraestructura.

9. Implementación. Se desarrolla en unidades verificables.

10. Pruebas. Se comprueban funciones, seguridad e integraciones.

11. Revisión. Se analizan cambios y decisiones.

12. Despliegue. Se publica dentro de un entorno controlado.

13. Monitoreo. Se observan errores, tiempos y recursos.

14. Mantenimiento. Se corrigen errores y actualizan dependencias.

15. Retiro. Los servicios obsoletos se eliminan de manera ordenada.

Pruebas backend

Pruebas unitarias

Evalúan funciones, clases y reglas de manera aislada.

Pruebas de integración

Comprueban la comunicación con bases de datos, colas, almacenamiento y servicios.

Pruebas de API

Verifican rutas, entradas, salidas, permisos y errores.

Pruebas de contrato

Comprueban que productores y consumidores mantengan acuerdos compatibles.

Pruebas end-to-end

Simulan procesos completos.

Pruebas de carga

Miden comportamiento ante tráfico esperado.

Pruebas de estrés

Incrementan carga hasta identificar límites y modos de fallo.

Pruebas de seguridad

Analizan autenticación, autorización, inyecciones, configuraciones y dependencias.

Pruebas de resiliencia

Introducen fallos controlados para observar recuperación.

Pruebas de migraciones

Comprueban cambios de esquema, compatibilidad y reversión.

Los entornos de prueba deben parecerse a producción sin utilizar innecesariamente datos personales reales.

Rendimiento

El rendimiento backend puede medirse mediante:

latencia;
throughput;
uso de CPU;
memoria;
conexiones;
consultas;
tamaño de respuesta;
tasa de errores.

Latencia

La latencia mide el tiempo desde una solicitud hasta su respuesta.

Puede dividirse en:

red;
cola;
procesamiento;
base de datos;
servicios externos;
serialización.

Los percentiles p50, p95 y p99 muestran cómo se comporta el sistema para diferentes proporciones de solicitudes.

El promedio puede ocultar experiencias muy lentas de una minoría significativa.

Throughput

Representa cuántas operaciones procesa el sistema por unidad de tiempo.

Optimización de consultas

Los índices, planes de ejecución y estructuras afectan el acceso a datos.

Problemas comunes:

consultas repetidas;
N+1 queries;
índices faltantes;
lecturas excesivas;
bloqueos;
conexiones sin límites.

Connection pooling

La creación de conexiones puede resultar costosa. Un pool reutiliza conexiones disponibles.

El tamaño excesivo puede saturar la base de datos.

Compresión

Reduce transferencia y aumenta uso de CPU. Debe aplicarse según tipo y tamaño de respuesta.

Escalabilidad

Escalamiento vertical

Aumenta CPU, memoria o capacidad de una máquina.

Resulta sencillo y posee límites físicos y económicos.

Escalamiento horizontal

Añade más instancias que atienden solicitudes.

Requiere distribución de tráfico, sesiones compartidas y coordinación.

Balanceo de carga

Distribuye solicitudes entre instancias.

Puede considerar:

disponibilidad;
región;
carga;
afinidad;
salud.

Replicación

Mantiene varias copias de datos o servicios.

Las réplicas de lectura pueden reducir carga sobre la base principal.

Particionamiento

Divide información según criterios como cliente, región, fecha o identificador.

Sharding

Distribuye subconjuntos de datos entre nodos.

Aumenta capacidad y complejidad de consultas, migraciones y balance.

Autoscaling

Ajusta la cantidad de instancias según métricas y demanda.

Kubernetes permite escalar cargas mediante recursos declarativos y métricas, mientras las plataformas serverless administran parte del escalamiento automáticamente.

Disponibilidad y resiliencia

La disponibilidad representa la proporción de tiempo en que un servicio funciona.

Las estrategias incluyen:

redundancia;
réplicas;
balanceadores;
zonas múltiples;
respaldos;
recuperación;
monitoreo;
despliegues graduales.

Timeouts

Toda comunicación externa debe tener límites de espera.

Sin timeout, una dependencia lenta puede consumir recursos indefinidamente.

Reintentos

Los reintentos pueden recuperar fallos temporales.

Deben utilizar:

límites;
retrasos;
backoff;
jitter;
idempotencia.

Los reintentos indiscriminados pueden aumentar una sobrecarga.

Circuit breaker

Interrumpe temporalmente solicitudes hacia una dependencia que falla repetidamente.

Bulkhead

Aísla recursos para evitar que un fallo consuma toda la capacidad.

Health checks

Permiten saber si una instancia puede recibir tráfico.

Graceful shutdown

Una aplicación debe dejar de aceptar trabajo nuevo, completar operaciones activas y cerrar conexiones de manera ordenada.

Respaldos y recuperación

Los respaldos protegen información frente a:

borrado;
corrupción;
errores;
ataques;
fallos físicos.

Un respaldo debe probarse mediante restauraciones.

Conceptos importantes:

RPO. Cantidad máxima de datos que puede perderse.

RTO. Tiempo máximo esperado para recuperar el servicio.

Las estrategias incluyen:

copias completas;
incrementales;
registros de transacciones;
replicación;
almacenamiento externo;
versiones.

La replicación no sustituye un respaldo, porque puede reproducir borrados y errores.

Observabilidad

La observabilidad permite comprender el comportamiento interno mediante salidas externas.

Registros

Los logs registran eventos y errores.

Deben incluir:

fecha;
nivel;
servicio;
identificador de solicitud;
operación;
resultado.

No deben almacenar contraseñas, tokens completos ni datos sensibles innecesarios.

Métricas

Representan valores agregados como:

solicitudes;
errores;
latencia;
CPU;
memoria;
colas;
conexiones.

Trazas

Las trazas distribuidas siguen una solicitud a través de varios servicios.

Alertas

Notifican cuando una métrica o evento supera un umbral.

Las alertas deben relacionarse con impacto y acciones posibles para evitar fatiga.

Correlation ID

Un identificador compartido permite seguir una operación entre componentes.

Seguridad backend

La seguridad debe incorporarse durante diseño, desarrollo, despliegue y operación.

OWASP ASVS proporciona una base para verificar controles técnicos de aplicaciones web y el OWASP API Security Top 10 describe riesgos frecuentes de las API.

Validación de entradas

Toda entrada externa debe considerarse no confiable.

La validación puede comprobar:

tipo;
longitud;
formato;
rango;
estructura;
reglas de negocio.

Inyección SQL

Ocurre cuando datos no confiables alteran una consulta.

Las mitigaciones incluyen:

consultas parametrizadas;
ORM utilizado correctamente;
permisos mínimos;
validación;
revisión.

Escapar manualmente cadenas no sustituye consultas parametrizadas.

Inyección de comandos

Puede ocurrir cuando una entrada modifica comandos ejecutados por el sistema operativo.

Conviene evitar construir comandos con texto proporcionado por usuarios.

Autorización rota

Una persona puede acceder a objetos o funciones que no le corresponden.

Cada solicitud debe verificar propiedad y permisos.

SSRF

Server-Side Request Forgery ocurre cuando el servidor consulta una URL controlada por un atacante sin validación suficiente.

Puede permitir acceso a servicios internos, metadatos o redes protegidas.

Rate limiting

Limita solicitudes por usuario, dirección, token o recurso.

Ayuda ante:

abuso;
fuerza bruta;
scraping;
costos;
denegación.

Gestión de secretos

Las credenciales deben almacenarse en servicios protegidos o variables seguras.

No deben incluirse en:

repositorios;
imágenes;
registros;
respuestas;
código frontend.

Cifrado

TLS protege datos en tránsito.

El cifrado en reposo protege determinados datos almacenados.

La gestión de claves forma parte del sistema de seguridad.

Dependencias

Las bibliotecas y contenedores pueden contener vulnerabilidades.

Las organizaciones deben revisar, actualizar y reducir dependencias.

Configuración

Los valores predeterminados, puertos y paneles administrativos pueden exponer riesgos.

Auditoría

Las operaciones sensibles deben registrar:

actor;
acción;
recurso;
fecha;
resultado.

Privacidad y protección de datos

El backend concentra frecuentemente información personal y comercial.

Las prácticas incluyen:

minimización;
propósito definido;
consentimiento;
retención limitada;
control de acceso;
cifrado;
eliminación;
exportación;
auditoría.

Los datos pueden clasificarse según sensibilidad.

La información de producción no debe copiarse indiscriminadamente hacia entornos de desarrollo.

Los respaldos también deben cumplir reglas de retención y eliminación.

La privacidad debe incorporarse en:

esquemas;
registros;
analítica;
integraciones;
permisos;
respuestas de API.

Backend y SEO

El backend influye en el SEO porque controla cómo se generan, almacenan y entregan las páginas.

Puede administrar:

códigos HTTP;
redirecciones;
URLs;
metadatos;
contenido;
canonical;
sitemaps;
datos estructurados;
idiomas;
paginación;
caché.

Un backend debe devolver códigos correctos.

Ejemplos:

una página válida devuelve 200;
un recurso inexistente devuelve 404;
una redirección permanente utiliza 301 o 308;
una indisponibilidad temporal puede utilizar 503.

Las páginas que muestran un mensaje de error con código 200 pueden producir soft 404 y confundir a buscadores y analítica.

La velocidad del servidor influye en el tiempo hasta el primer byte y en la experiencia.

El backend también puede generar:

sitemaps;
feeds;
páginas por producto;
enlaces;
contenidos localizados.

Los filtros y parámetros deben administrarse para evitar combinaciones ilimitadas, duplicación y sobrecarga.

Backend y analítica

El backend puede registrar eventos que no dependen del navegador.

Ejemplos:

pedido confirmado;
pago recibido;
renovación;
devolución;
lead asignado;
llamada completada;
producto enviado.

La medición server-side reduce determinadas pérdidas ocasionadas por bloqueadores y errores frontend.

No elimina obligaciones de consentimiento, privacidad y exactitud.

La deduplicación resulta necesaria cuando un mismo evento se envía desde frontend y backend.

El backend puede enriquecer eventos con:

identificador interno;
estado;
valor;
producto;
campaña;
canal;
región.

Debe evitar enviar datos personales prohibidos o innecesarios hacia plataformas de terceros.

Aplicaciones en marketing

El backend sostiene numerosos procesos de marketing y ventas.

Generación de leads

Puede:

recibir formularios;
validar datos;
detectar duplicados;
registrar UTM;
calcular puntuaciones;
asignar vendedores;
activar mensajes;
actualizar CRM.

CRM

Administra:

contactos;
empresas;
oportunidades;
actividades;
estados;
responsables;
historial.

Automatización de marketing

El backend conecta eventos y acciones.

Puede iniciar una secuencia cuando:

un usuario descarga un recurso;
abandona un carrito;
solicita información;
renueva una suscripción;
alcanza una puntuación.

Personalización

Puede seleccionar contenidos, productos y ofertas según datos autorizados.

Las reglas deben evitar inferencias sensibles y manipulaciones indebidas.

E-commerce

Administra productos, inventarios, pedidos, clientes, pagos, envíos y devoluciones.

SEO

Genera páginas, sitemaps, enlaces, datos estructurados y redirecciones.

SEO local

Puede administrar:

ciudades;
sucursales;
horarios;
inventarios;
zonas de cobertura;
teléfonos;
páginas regionales.

Marketing de contenidos

Conserva artículos, autores, revisiones, etiquetas, permisos y calendarios.

Publicidad digital

Puede registrar conversiones server-side, sincronizar audiencias y consolidar datos.

Programas de fidelización

Calcula puntos, niveles, recompensas y vencimientos.

Marketing de afiliación

Administra enlaces, atribución, comisiones, pagos y prevención de fraude.

Marketing de influencers

Puede conservar perfiles, campañas, entregables, métricas y pagos.

Marketing de eventos

Gestiona registros, boletos, pagos, agendas, asistentes y certificados.

Directorios

Administra perfiles, categorías, búsquedas, ubicaciones, reseñas y contactos.

Sistemas de cotización

Calcula precios según productos, regiones, configuraciones y políticas.

Marketing conversacional

Conecta canales, usuarios, agentes humanos, CRM, historial y bases de conocimiento.

Inteligencia competitiva

Almacena y procesa información pública recopilada bajo reglas legales y técnicas.

Analítica

Consolida datos de campañas, ventas, productos, clientes y canales.

Ventajas del concepto

Centralización de reglas. Las decisiones se aplican de manera consistente.

Protección de datos. La información sensible permanece fuera del cliente.

Persistencia. Los datos sobreviven a sesiones y dispositivos.

Integración. Conecta aplicaciones y proveedores.

Escalabilidad. Puede distribuir capacidad y almacenamiento.

Automatización. Ejecuta tareas sin intervención constante.

Personalización. Procesa datos para adaptar servicios.

Seguridad. Controla identidades, permisos y operaciones.

Trazabilidad. Registra eventos y cambios.

Multicanalidad. Un backend puede atender web, móvil, voz y sistemas externos.

Reutilización. Las API permiten que varias interfaces utilicen funciones comunes.

Procesamiento asíncrono. Las tareas pesadas pueden ejecutarse fuera de la solicitud.

Consistencia. Las transacciones y restricciones preservan reglas.

Observabilidad. Los operadores pueden analizar el sistema.

Continuidad. Los respaldos y redundancia reducen interrupciones.

Limitaciones

Complejidad. Los sistemas distribuidos requieren coordinación y conocimientos especializados.

Costo operativo. Servidores, bases de datos, monitoreo y soporte generan gastos.

Seguridad. Una vulnerabilidad puede exponer información o funciones críticas.

Dependencia de red. Los clientes necesitan conectividad para utilizar servicios remotos.

Escalabilidad difícil. El crecimiento puede revelar cuellos de botella.

Mantenimiento. Frameworks, sistemas operativos y dependencias requieren actualizaciones.

Migraciones. Los cambios de datos pueden resultar riesgosos.

Dependencia de proveedores. Los servicios administrados pueden producir vendor lock-in.

Latencia. Las solicitudes atraviesan redes, servicios y bases.

Consistencia distribuida. Varias copias pueden presentar diferencias temporales.

Observabilidad compleja. Los errores pueden atravesar muchos componentes.

Costos variables. El consumo puede crecer inesperadamente.

Disponibilidad. Las interrupciones afectan múltiples clientes.

Deuda técnica. Las decisiones rápidas acumulan dificultades futuras.

Privacidad. La centralización aumenta responsabilidad sobre datos.

Consideraciones técnicas o estadísticas

Tráfico

solicitudes por segundo;
usuarios concurrentes;
conexiones abiertas;
volumen por región;
picos.

Rendimiento

latencia p50;
latencia p95;
latencia p99;
throughput;
tiempo de consulta;
tamaño de respuesta.

Disponibilidad

porcentaje de uptime;
errores por periodo;
tiempo medio entre fallos;
tiempo medio de recuperación.

Bases de datos

conexiones;
consultas lentas;
bloqueos;
tamaño;
crecimiento;
uso de índices;
replicación.

Caché

hit ratio;
miss ratio;
expiraciones;
memoria;
evicciones.

Colas

profundidad;
edad del mensaje;
tasa de procesamiento;
reintentos;
mensajes fallidos.

Seguridad

intentos fallidos;
accesos denegados;
vulnerabilidades;
eventos sospechosos;
rotación de secretos.

Costos

costo por solicitud;
costo por usuario;
almacenamiento;
transferencia;
cómputo;
servicios administrados.

Negocio

leads procesados;
pedidos;
pagos;
conversiones;
errores comerciales;
tiempo de automatización.

Las métricas necesitan contexto. Una latencia aceptable para un proceso nocturno puede ser inadecuada para una búsqueda interactiva.

Herramientas y plataformas

Node.js. Entorno para ejecutar JavaScript y TypeScript del lado del servidor.

Express. Framework minimalista para aplicaciones Node.js.

NestJS. Framework estructurado para Node.js y TypeScript.

Django. Framework web integral para Python.

Flask. Framework ligero para Python.

FastAPI. Framework para API basado en Python y tipos.

Laravel. Framework PHP para aplicaciones web.

Symfony. Ecosistema PHP de componentes y framework.

Ruby on Rails. Framework web para Ruby.

Spring Boot. Plataforma para aplicaciones y servicios Java.

ASP.NET Core. Framework multiplataforma para aplicaciones .NET.

Phoenix. Framework para Elixir.

PostgreSQL. Base de datos relacional de código abierto.

MySQL. Sistema de gestión de bases relacionales.

MariaDB. Base relacional derivada de MySQL.

SQLite. Base de datos incorporada y basada en archivos.

MongoDB. Base de datos documental.

Redis. Almacén en memoria utilizado para caché, sesiones y mensajería.

Elasticsearch. Motor distribuido de búsqueda y análisis.

OpenSearch. Motor abierto de búsqueda y analítica.

RabbitMQ. Broker de mensajes.

Apache Kafka. Plataforma distribuida de eventos.

Nginx. Servidor web y proxy inverso.

Apache HTTP Server. Servidor web extensible.

Docker. Plataforma para construir y ejecutar contenedores.

Kubernetes. Plataforma para administrar cargas de trabajo contenerizadas.

AWS. Proveedor de nube con cómputo, bases, almacenamiento y servicios serverless.

Microsoft Azure. Plataforma de nube y servicios empresariales.

Google Cloud. Plataforma de cómputo, datos e inteligencia artificial.

AWS Lambda. Servicio para ejecutar código sin administrar directamente servidores.

Firebase. Plataforma de backend y servicios para aplicaciones.

Supabase. Plataforma basada en PostgreSQL con autenticación, almacenamiento y funciones.

Appwrite. Backend de código abierto con autenticación, datos y almacenamiento.

Hasura. Plataforma que expone API GraphQL sobre datos.

Git. Sistema de control de versiones.

GitHub, GitLab y Bitbucket. Plataformas de repositorios, revisión y automatización.

OpenAPI. Especificación para describir API HTTP.

Postman. Herramienta para diseñar, probar y documentar API.

Grafana. Plataforma para visualización y observabilidad.

Prometheus. Sistema de métricas y alertas.

OpenTelemetry. Estándares y herramientas para telemetría.

Sentry. Plataforma para errores y rendimiento.

La selección debe considerar escala, experiencia, seguridad, costos, soporte, portabilidad y vida útil.

Relación con otros conceptos

Frontend. Capa visible que interactúa con el usuario.

Full stack. Desarrollo que comprende frontend y backend.

Desarrollo web. Campo general que incluye interfaces, servidores, datos e infraestructura.

Servidor. Sistema que proporciona recursos o servicios a clientes.

Servidor web. Procesa solicitudes HTTP y entrega recursos.

Cliente-servidor. Modelo de comunicación entre clientes y servicios.

API. Contrato para intercambiar datos y operaciones.

REST. Estilo arquitectónico para sistemas distribuidos.

GraphQL. Lenguaje de consulta y runtime para API.

Webhook. Notificación enviada mediante HTTP cuando ocurre un evento.

WebSocket. Comunicación bidireccional persistente.

HTTP. Protocolo para solicitudes y respuestas web.

HTTPS. HTTP protegido mediante TLS.

JSON. Formato frecuente para intercambio de datos.

Base de datos. Sistema para almacenar y consultar información.

SQL. Lenguaje para bases relacionales.

NoSQL. Categoría amplia de sistemas no relacionales.

Caché. Almacenamiento temporal para acelerar accesos.

Cola de mensajes. Sistema para distribuir trabajos asíncronos.

Microservicios. Arquitectura formada por servicios pequeños.

Monolito modular. Aplicación única con módulos internos delimitados.

Serverless. Modelo administrado de ejecución y servicios.

Computación en la nube. Provisión de infraestructura y servicios remotos.

Contenedor. Unidad empaquetada de software y dependencias.

Docker. Plataforma de contenedores.

Kubernetes. Orquestador de cargas contenerizadas.

Autenticación. Verificación de identidad.

Autorización. Control de permisos.

OAuth. Protocolo de autorización delegada.

JSON Web Token. Formato de claims firmados o protegidos.

Observabilidad. Comprensión del sistema mediante telemetría.

DevOps. Integración de desarrollo y operación.

CI/CD. Automatización de integración, pruebas y despliegues.

Ciberseguridad. Protección de sistemas y datos.

Backend for Frontend. Backend adaptado a un cliente específico.

Headless CMS. Gestor de contenidos desacoplado de la presentación.

No-code. Desarrollo mediante componentes visuales.

Low-code. Desarrollo visual extensible mediante código.

Programación asistida por inteligencia artificial. Uso de IA durante el desarrollo.

Vibe coding. Desarrollo conversacional mediante IA.

Desarrollo agéntico. Uso de agentes durante el ciclo de software.

Automatización de marketing. Conecta eventos, datos y comunicaciones.

CRM. Sistema de gestión de relaciones con clientes.

E-commerce. Comercio realizado mediante plataformas digitales.

Diferencias entre backend y frontend

El frontend presenta información y recibe interacciones.

El backend procesa las operaciones, protege los datos y aplica reglas.

El frontend puede validar que un correo tenga un formato aparente correcto. El backend debe repetir la validación, verificar duplicados, aplicar restricciones y almacenar la información.

El frontend puede ocultar un botón para usuarios sin permiso. El backend debe impedir que la operación se ejecute aunque alguien envíe directamente la solicitud.

Diferencias entre backend y servidor

El servidor es la máquina o programa que proporciona servicios.

El backend comprende el conjunto completo de lógica, datos, servicios e infraestructura.

Un backend puede ejecutarse en uno o varios servidores.

Una plataforma serverless contiene servidores, aunque el proveedor los administra.

Diferencias entre backend y base de datos

La base de datos almacena y consulta información.

El backend decide qué operaciones deben ejecutarse, quién puede realizarlas y cómo se coordinan.

Conectar directamente el frontend con una base de datos sin reglas ni controles puede exponer información y operaciones.

Determinadas plataformas administradas permiten conexiones directas mediante políticas de seguridad, aunque esas políticas funcionan como parte de la lógica backend.

Diferencias entre backend y API

Una API constituye una interfaz mediante la cual el backend expone determinadas capacidades.

El backend puede incluir procesos internos que no se publican mediante API.

Una API también puede existir entre componentes internos o servicios de terceros.

Diferencias entre backend y full stack

El backend representa la capa interna.

Full stack describe el trabajo que abarca frontend, backend y frecuentemente datos, infraestructura o despliegue.

El alcance de un puesto full stack varía según la organización.

Diferencias entre backend tradicional y serverless

En un backend tradicional, la organización administra servidores o contenedores que permanecen ejecutándose.

En serverless, la plataforma administra la infraestructura subyacente y activa funciones o servicios según solicitudes y eventos.

Serverless puede reducir tareas operativas y aumentar dependencia del proveedor.

Ambos enfoques pueden combinarse dentro de una misma aplicación.

Buenas prácticas

Definir reglas de negocio explícitas. Las decisiones deben documentarse y probarse.

Diseñar contratos claros. Las API necesitan entradas, salidas y errores consistentes.

Validar toda entrada. Los datos externos no deben considerarse confiables.

Aplicar autorización en cada operación. El acceso a un objeto debe verificarse.

Utilizar privilegio mínimo. Usuarios y servicios reciben únicamente permisos necesarios.

Proteger secretos. Las credenciales deben mantenerse fuera del código.

Utilizar consultas parametrizadas. Reduce riesgos de inyección.

Mantener transacciones breves. Disminuye bloqueos y conflictos.

Diseñar operaciones idempotentes. Facilita reintentos y recuperación.

Establecer timeouts. Las dependencias no deben bloquear recursos indefinidamente.

Aplicar reintentos controlados. Deben incluir backoff y límites.

Limitar solicitudes. El rate limiting reduce abusos.

Registrar eventos relevantes. Los logs deben ser útiles y proteger datos.

Implementar métricas y trazas. La observabilidad debe incorporarse desde el diseño.

Mantener respaldos. Las copias deben probarse mediante restauración.

Separar entornos. Desarrollo, pruebas y producción requieren configuraciones distintas.

Automatizar pruebas. Las reglas y contratos deben verificarse continuamente.

Utilizar migraciones versionadas. Los cambios de datos necesitan trazabilidad.

Actualizar dependencias. Las vulnerabilidades y compatibilidades cambian.

Reducir dependencias innecesarias. Cada paquete aumenta superficie de mantenimiento.

Diseñar para fallos. Las redes y servicios externos pueden fallar.

Evitar microservicios prematuros. La complejidad debe justificarse.

Mantener módulos cohesionados. Las responsabilidades deben ser comprensibles.

Documentar decisiones. La arquitectura necesita contexto y motivos.

Aplicar despliegues graduales. Las versiones nuevas deben limitar inicialmente su impacto.

Monitorear costos. La escala y los servicios administrados pueden aumentar gastos.

Preparar estrategia de recuperación. Deben definirse RPO, RTO y procedimientos.

Proteger la privacidad. Los datos deben minimizarse y conservarse solamente el tiempo necesario.

Realizar revisiones de seguridad. Los sistemas públicos necesitan evaluación especializada.

Errores comunes

Confiar en la validación frontend. Las solicitudes pueden modificarse o enviarse directamente.

Guardar contraseñas sin hash seguro. Una filtración expone inmediatamente credenciales.

Incluir secretos en el repositorio. Las claves pueden permanecer dentro del historial.

Construir consultas con concatenación. Produce vulnerabilidades de inyección.

No verificar propiedad de objetos. Los usuarios pueden acceder a datos ajenos.

Utilizar códigos HTTP incorrectos. Los clientes no pueden interpretar adecuadamente el resultado.

Devolver errores internos completos. Las trazas pueden revelar estructura, rutas y secretos.

Registrar datos sensibles. Los logs se convierten en una fuente de exposición.

No establecer límites. Las solicitudes pueden consumir recursos excesivos.

Realizar tareas lentas dentro de la solicitud. Aumenta latencia y fallos.

Enviar correos sin cola. Los retrasos del proveedor bloquean la respuesta.

Omitir idempotencia. Los reintentos duplican pagos, pedidos o mensajes.

No utilizar timeouts. Las conexiones quedan abiertas indefinidamente.

Reintentar sin control. Una dependencia caída recibe más carga.

Añadir índices indiscriminadamente. Los índices aceleran lecturas y encarecen escrituras.

No revisar planes de consulta. Las operaciones se degradan con el crecimiento.

Usar una base para todos los casos. Cada tipo de dato puede necesitar estrategias distintas.

Crear microservicios demasiado pronto. Aumenta complejidad sin beneficios.

Compartir una base sin límites entre servicios. Produce acoplamiento oculto.

No versionar cambios de esquema. Los entornos quedan incompatibles.

Confundir replicación con respaldo. Los errores se replican.

No probar restauraciones. Un respaldo puede ser inutilizable.

Operar sin observabilidad. Los fallos se detectan mediante quejas de usuarios.

Confiar en promedios. Ocultan las solicitudes más lentas.

Utilizar producción para pruebas. Puede modificar datos y afectar clientes.

Conceder permisos administrativos a todos los servicios. Aumenta el impacto de una vulnerabilidad.

Depender de un proveedor sin plan de salida. Los cambios comerciales afectan la continuidad.

Generar backend con IA sin revisión. El código puede incluir fallos de seguridad y arquitectura.

Desafíos éticos y organizacionales

Privacidad. El backend concentra datos personales, comerciales y conductuales.

Vigilancia. Los sistemas pueden registrar actividades más allá de lo necesario.

Consentimiento. Las personas deben comprender qué datos se recopilan y para qué.

Sesgo. Las reglas y modelos pueden afectar grupos de manera desigual.

Decisiones automatizadas. Los sistemas pueden influir en precios, acceso, crédito, empleo o atención.

Transparencia. Las organizaciones deben explicar procesos relevantes cuando corresponda.

Seguridad. Una vulnerabilidad puede afectar a numerosos usuarios simultáneamente.

Concentración de datos. El valor acumulado aumenta el impacto de filtraciones.

Dependencia tecnológica. Los proveedores pueden controlar infraestructura y condiciones.

Sostenibilidad. Los servicios consumen energía, almacenamiento y transferencia.

Responsabilidad. Debe definirse quién aprueba reglas y responde por fallos.

Mantenimiento. Las decisiones actuales trasladan costos hacia equipos futuros.

Trabajo invisible. La disponibilidad continua requiere operación, guardias, soporte y respuesta a incidentes.

Automatización. Las organizaciones pueden eliminar revisión humana de procesos sensibles.

Gobernanza. Los servicios necesitan propietarios, políticas, documentación y auditoría.

Gobernanza organizacional

Una estrategia de backend puede incluir:

catálogo de servicios;
propietarios;
estándares de API;
convenciones de datos;
clasificación de información;
niveles de riesgo;
control de acceso;
gestión de secretos;
revisión de código;
pruebas;
análisis de seguridad;
observabilidad;
respaldos;
continuidad;
control de costos;
políticas de dependencias;
procedimientos de retiro.

Cada servicio debe documentar:

propósito;
responsables;
consumidores;
datos;
permisos;
dependencias;
métricas;
alertas;
respaldos;
procedimiento de despliegue;
estrategia de recuperación.

Los servicios sin usuarios o responsables deben retirarse de forma controlada.

Impacto actual

El backend se ha convertido en la infraestructura operativa de negocios digitales, servicios públicos, plataformas, comercios y sistemas internos.

La expansión de API permite que una misma operación se utilice desde sitios, aplicaciones móviles, agentes, dispositivos e integraciones.

Los servicios de nube reducen la barrera para desplegar sistemas, aunque trasladan decisiones hacia arquitectura, costos, seguridad y dependencia.

Los contenedores y Kubernetes facilitan automatizar despliegues y escalamiento en sistemas complejos, mientras exigen conocimientos especializados.

Serverless permite construir procesos activados por eventos sin administrar directamente servidores, lo que resulta útil en automatizaciones, integraciones y cargas variables.

Las API se han convertido en objetivos importantes de ataques porque exponen datos y funciones de negocio. La autorización, los límites y la gestión de inventario adquieren mayor relevancia.

La observabilidad se considera una función fundamental porque las aplicaciones distribuidas no pueden comprenderse mediante un único archivo de registro.

En marketing, el backend conecta captación, CRM, ventas, pagos, analítica y automatización. Su calidad determina si los datos llegan completos, los prospectos reciben seguimiento y las conversiones pueden atribuirse correctamente.

La programación asistida por IA acelera la implementación de servicios y consultas. El valor profesional se desplaza hacia modelado, arquitectura, seguridad, pruebas y revisión.

Futuro y tendencias

Arquitecturas híbridas. Monolitos, microservicios y funciones coexistirán dentro de un mismo sistema.

Serverless más amplio. Bases, colas, flujos y contenedores administrados reducirán tareas operativas.

Ejecución en el borde. Parte del backend se ejecutará cerca del usuario para reducir latencia.

Backends distribuidos globalmente. Los datos y servicios se replicarán entre regiones.

Bases de datos serverless. La capacidad se ajustará automáticamente según demanda.

API composables. Las aplicaciones combinarán servicios especializados.

Arquitecturas orientadas a eventos. Los sistemas reaccionarán a cambios mediante flujos asíncronos.

Agentes de inteligencia artificial. Los backends proporcionarán herramientas, memoria, permisos y datos para agentes.

Backend para agentes. Las API se diseñarán para clientes humanos y sistemas autónomos.

Desarrollo agéntico. Los agentes implementarán, probarán y operarán servicios bajo supervisión.

Observabilidad asistida por IA. Los sistemas analizarán trazas, registros y métricas para proponer diagnósticos.

Remediación automática. Determinados incidentes activarán respuestas controladas.

Seguridad continua. Las pruebas y políticas se aplicarán durante desarrollo y ejecución.

Zero trust. Los servicios verificarán identidad y autorización en cada interacción.

Datos en tiempo real. Las empresas procesarán eventos conforme ocurren.

Privacidad computacional. Crecerán técnicas de minimización, anonimización y procesamiento protegido.

Modelos locales. Algunas operaciones de IA se ejecutarán en infraestructura privada.

Interfaces naturales. Los usuarios crearán procesos backend mediante lenguaje natural.

Contratos generados. Las especificaciones y pruebas de API se producirán conjuntamente.

Mayor interoperabilidad. Los estándares facilitarán conectar herramientas y agentes.

Gobernanza automatizada. Las plataformas detectarán permisos, datos sensibles y servicios abandonados.

FinOps. El control de costos se integrará con arquitectura y operación.

Sostenibilidad. La eficiencia energética formará parte de las decisiones técnicas.

Plataformas internas. Las organizaciones crearán caminos estandarizados para desplegar servicios.

Backend as a Service especializado. Aparecerán plataformas adaptadas a sectores y procesos.

Revalorización de la simplicidad. Los equipos evitarán arquitecturas distribuidas cuando un sistema modular resulte suficiente.

Véase también

Referencias

Bibliografía

Bass, Len; Clements, Paul; Kazman, Rick. Software Architecture in Practice. Addison-Wesley.
Burns, Brendan. Designing Distributed Systems. O’Reilly Media.
Evans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley.
Ford, Neal; Richards, Mark. Fundamentals of Software Architecture. O’Reilly Media.
Fowler, Martin. Patterns of Enterprise Application Architecture. Addison-Wesley.
Kleppmann, Martin. Designing Data-Intensive Applications. O’Reilly Media.
Newman, Sam. Building Microservices. O’Reilly Media.
Nygard, Michael T. Release It!. Pragmatic Bookshelf.
Richardson, Chris. Microservices Patterns. Manning.
Richards, Mark. Software Architecture Patterns. O’Reilly Media.
Richardson, Leonard; Amundsen, Mike. RESTful Web APIs. O’Reilly Media.
Site Reliability Engineering Team. Site Reliability Engineering: How Google Runs Production Systems. O’Reilly Media.
Tanenbaum, Andrew S.; Van Steen, Maarten. Distributed Systems. Pearson.
Thomas, David; Hunt, Andrew. The Pragmatic Programmer. Addison-Wesley.
OWASP Foundation. Application Security Verification Standard.
PostgreSQL Global Development Group. PostgreSQL Documentation.