Cómo se arma un sitio web, de punta a punta

Monolito

Una sola aplicación y un solo deploy con todo adentro: UI o API, lógica y acceso a datos. Django, Rails, Laravel, NestJS o Express "todo en uno".

Explicado fácil: un restaurante con una sola cocina donde se hace todo: entradas, platos y postres. Fácil de manejar. Si se rompe el horno, no sale nada.

Usalo cuando: MVP, startup, equipo de 1 a 15 devs, dominio que todavía cambia.

Monolito modular

Un solo deploy, pero dividido internamente en módulos con límites claros (usuarios, pagos, catálogo) que solo se hablan por interfaces públicas.

Explicado fácil: la misma cocina única, pero dividida en estaciones con su propio cocinero (pastas, parrilla, postres) que se pasan los platos por una ventanilla. Si mañana querés mudar la parrilla a otro local, ya está separada.

Usalo cuando: el producto crece y querés prepararte para microservicios sin pagar su costo todavía.

Microservicios

Muchos servicios chicos, cada uno con su propia base de datos y su deploy, que se comunican por HTTP/gRPC o eventos.

Explicado fácil: un patio de comidas: cada local es independiente, tiene su cocina, su caja y su personal. Si se cae la pizzería, el resto sigue vendiendo. Pero coordinar un combo entre tres locales es más complicado.

Usalo cuando: muchos equipos trabajan sobre el mismo producto y el monolito ya frena los deploys.

Serverless

Funciones que corren ante un evento (request HTTP, archivo subido, cron). AWS Lambda, Vercel Functions, Cloudflare Workers, Google Cloud Functions.

Explicado fácil: en vez de tener tu cocina, pedís un cocinero por delivery cada vez que llega un cliente. Si no viene nadie, no pagás nada. Si vienen mil, te mandan mil. El primero puede tardar un poco en llegar (cold start).

Usalo cuando: tráfico variable, webhooks, tareas puntuales, landings con API chica.

Event-driven

Los componentes publican eventos ("pedido_creado") en un broker (Kafka, RabbitMQ, SQS) y otros los consumen sin conocerse entre sí.

Explicado fácil: una cocina con comandas colgadas en un riel. El mozo cuelga "pedido mesa 4" y se va; la parrilla, la caja y el que arma el ticket la ven y cada uno hace su parte, sin hablar entre ellos.

Usalo cuando: procesos asíncronos (mails, facturación, notificaciones), integraciones entre sistemas.

Capas / Hexagonal / Clean

No definen cómo se despliega, sino cómo se ordena el código. En capas: controlador → servicio → repositorio. Hexagonal: el dominio en el centro y la DB, HTTP o colas como "adaptadores" intercambiables. Ver hexagonal en detalle.

Explicado fácil: la receta (lógica de negocio) no depende de qué horno uses. Hoy cocinás con gas, mañana con eléctrico, y la receta no cambia. En código: hoy Postgres, mañana Mongo, y la lógica sigue igual.

Usalo cuando: la lógica de negocio es rica y va a vivir años.

BFF (Backend for Frontend)

Una capa de API pensada para un frontend específico (web, mobile) que agrega y adapta datos de varios servicios internos.

Explicado fácil: un mozo distinto para el salón y otro para el delivery. Los dos piden a la misma cocina, pero cada uno arma la entrega como la necesita su cliente.

Usalo cuando: web y app mobile necesitan datos muy distintos del mismo backend.

Real-time (WebSockets / SSE)

Conexión persistente para empujar datos al cliente: chats, dashboards en vivo, juegos, streaming de respuestas de IA.

Explicado fácil: en vez de que el cliente pregunte cada 5 segundos "¿ya está mi pedido?", queda una línea telefónica abierta y la cocina avisa apenas está. Es lo que usa WhatsApp Web.

Usalo cuando: el usuario necesita ver cambios al instante. Node.js brilla acá.

MVC (Modelo, Vista, Controlador)

Separa la app en tres partes. El Modelo maneja los datos y las reglas. La Vista es lo que ve el usuario. El Controlador recibe la acción del usuario, le pide cosas al modelo y elige qué vista mostrar.

Explicado fácil: en un restaurante, el mozo es el controlador (toma tu pedido), la cocina es el modelo (prepara la comida con sus recetas) y el plato servido es la vista (lo que ves).

Lo usan: Django (lo llama MVT), Rails, Laravel, Spring MVC, NestJS con controladores y servicios.

Arquitectura en capas

El código se apila en capas y cada una solo habla con la de abajo: presentación (rutas, controladores) → negocio (servicios, reglas) → datos (repositorios, base de datos).

Explicado fácil: un edificio por pisos. En planta baja atienden al público, en el primer piso están los que deciden, en el subsuelo está el archivo. El de planta baja nunca baja directo al archivo: le pide al de arriba.

Ejemplo: POST /pedidos → PedidosController → PedidosService.crear() valida stock → PedidosRepository.guardar().

CQRS

Command Query Responsibility Segregation: un modelo para escribir (comandos: crear, modificar) y otro distinto para leer (consultas), muchas veces con bases de datos diferentes.

Explicado fácil: en un banco hay una ventanilla para depositar y otra para consultar el saldo. Cada una está optimizada para lo suyo y no se traban entre sí.

Usalo cuando: las lecturas son muchísimas más que las escrituras, o necesitan otra forma (un dashboard que lee de una tabla ya resumida).

Flux / store único

Todo el estado de la app vive en un solo lugar (el store). Los componentes no se modifican entre sí: disparan acciones, el store cambia y la vista se vuelve a dibujar.

Explicado fácil: un pizarrón central en la oficina. Nadie se pasa papelitos: todos escriben y leen del pizarrón, así nadie queda desactualizado.

Lo usan: Redux, Zustand, Pinia. También MVVM en Angular, Vue y apps mobile.

Singleton

Garantiza que exista una sola instancia de algo en toda la app.

Explicado fácil: el presidente de un país: hay uno solo y todos le hablan al mismo.

En web: el pool de conexiones a la base de datos o el cliente de Prisma. Si creás uno por request, agotás las conexiones.

Factory

Una función que crea el objeto correcto según un dato, sin que quien la llama sepa cuál clase exacta se usa.

Explicado fácil: pedís "una bebida fría" y la máquina decide si te da agua, gaseosa o jugo según el botón.

En web: crearPasarela("mercadopago") devuelve la integración de Mercado Pago; con "stripe", la de Stripe.

Builder

Arma un objeto complejo paso a paso, encadenando métodos.

Explicado fácil: armar un sándwich en Subway: elegís pan, después el relleno, después los aderezos.

En web: los query builders: db.select().from(users).where(...).limit(10) en Drizzle o Knex.

Adapter

Hace que dos cosas incompatibles puedan trabajar juntas, traduciendo una interfaz a otra.

Explicado fácil: el adaptador de enchufe que usás cuando viajás a otro país.

En web: una API vieja devuelve first_name y tu app usa nombre. Un adapter traduce las respuestas para que el resto del código no se entere.

Decorator

Le agrega comportamiento a una función u objeto sin modificar su código.

Explicado fácil: ponerle funda a un celular: sigue siendo el mismo celular, pero ahora además está protegido.

En web: @app.get("/") en FastAPI o @login_required en Django: envuelven tu función para registrarla como ruta o exigir login.

Facade

Una interfaz simple que esconde un sistema complicado detrás.

Explicado fácil: el botón de encendido de la compu. Apretás uno y por detrás arrancan decenas de procesos.

En web: checkout.pagar(carrito) que por dentro valida stock, cobra, genera la factura y manda el mail.

Observer

Un objeto avisa automáticamente a todos los que se suscribieron cuando algo cambia.

Explicado fácil: suscribirte a un canal de YouTube: cuando sube un video, te llega la notificación sin que tengas que entrar a mirar.

En web: addEventListener, el EventEmitter de Node, los stores de React, los signals de Django.

Strategy

Tenés varias formas de hacer lo mismo y elegís cuál usar en el momento, sin llenar el código de if.

Explicado fácil: para llegar al trabajo podés ir en auto, colectivo o bici. El destino es el mismo, cambia la estrategia.

En web: calcular el envío (estándar, express, retiro en local) o las estrategias de login en Passport.js.

Chain of Responsibility (middleware)

Un pedido pasa por una cadena de manejadores; cada uno hace su parte y decide si lo pasa al siguiente o lo corta.

Explicado fácil: los controles de un aeropuerto: check-in, migraciones, seguridad. Si uno te frena, no llegás al avión.

En web: el middleware de Express o FastAPI: logs → CORS → autenticación → rate limit → tu ruta.

Inyección de dependencias

Una clase no crea lo que necesita: se lo pasan desde afuera. Así podés cambiarlo o reemplazarlo en los tests.

Explicado fácil: un cocinero que no sale a comprar los ingredientes: se los traen. Si mañana cambiás de proveedor, el cocinero no se entera.

En web: Depends() en FastAPI, los constructores de NestJS, Spring en Java.

Repository

Una clase que esconde cómo se guardan los datos. El resto del código pide usuarios.buscarPorEmail() sin saber si atrás hay SQL, Mongo o una API.

Explicado fácil: el bibliotecario: le pedís un libro y te lo trae; no te importa en qué estante estaba.

En web: la capa de datos en arquitectura en capas y hexagonal; los repositorios de TypeORM y Spring Data.

SPA: cocinás vos en la mesa

El servidor te manda una página casi vacía más un paquete de JavaScript. Tu navegador "cocina" la página: pide los datos a la API y arma el HTML.

Ejemplo: Gmail o un panel de administración. Al entrar ves un spinner un segundo y después todo es fluido, porque al navegar no se recarga la página.

Problema: Google, o WhatsApp cuando previsualiza un link, al principio ven una página vacía. Malo para SEO.

SSR: el cocinero cocina cuando pedís

En cada visita, el servidor busca los datos, arma el HTML completo y te lo manda listo para mostrar.

Ejemplo: la página de resultados de una búsqueda, o un perfil con datos que cambian todo el tiempo. Siempre ves lo último.

Problema: cada visita gasta servidor. Con mucho tráfico cuesta más y la respuesta tarda un poco más.

SSG: viandas preparadas a la mañana

Cuando hacés el deploy (el "build"), se generan todas las páginas como archivos HTML y se suben a un CDN. Nadie cocina en el momento.

Ejemplo: un blog o la landing de una empresa. Se sirve instantáneo y casi gratis.

Problema: si cambiás un texto hay que volver a hacer build y deploy. Con 100.000 productos el build tarda horas.

Islands: plato listo con un par de extras en vivo

Casi toda la página llega como HTML estático, sin JavaScript. Solo algunas "islas" interactivas (el carrito, el buscador, un carrusel) cargan JS.

Ejemplo: la nota de un diario. El texto es estático y solo el botón de "me gusta" y los comentarios son interactivos. Carga mucho más rápido en celulares.

HTMX: el mozo trae solo lo que cambió

En vez de recargar la página entera o usar React, el servidor devuelve pedacitos de HTML que reemplazan una parte de la pantalla.

Ejemplo: apretás "cargar más comentarios" y el servidor (Django, FastAPI) te devuelve solo el HTML de los 10 comentarios nuevos.

Django

El framework "completo": base de datos (ORM), migraciones, login de usuarios, panel de administración, formularios y seguridad, todo listo desde el día uno.

Explicado fácil: una casa amueblada. Te mudás y ya tenés cama, heladera y cocina. Si querés cambiar algo, podés, pero la mayoría de las cosas ya están resueltas.

# views.py
def productos(request):
    datos = list(Producto.objects.values("nombre", "precio"))
    return JsonResponse(datos, safe=False)

# urls.py
path("productos/", productos)

Usalo para: e-commerce, backoffices, sistemas con usuarios y panel de admin. Instagram arrancó con Django.

Flask

Un framework chiquito: te da las rutas y poco más. La base de datos, el login y lo demás los agregás vos con extensiones.

Explicado fácil: un monoambiente vacío. Entrás rápido y lo decorás como quieras, pero cada mueble lo tenés que traer vos.

from flask import Flask
app = Flask(__name__)

@app.get("/hola")
def hola():
    return {"mensaje": "Hola"}

Usalo para: APIs chicas, prototipos, scripts que necesitan una web simple, aprender cómo funciona un backend.

FastAPI

Pensado para hacer APIs rápido y bien: valida los datos con los tipos, genera la documentación sola en /docs y es async. Ver FastAPI en detalle.

Explicado fácil: un departamento moderno pensado para una sola cosa, hacer APIs. No trae panel de admin, pero lo que trae está muy bien hecho.

from fastapi import FastAPI
app = FastAPI()

@app.get("/hola/{nombre}")
async def hola(nombre: str):
    return {"mensaje": f"Hola {nombre}"}

Usalo para: APIs para un frontend o app mobile, microservicios, proyectos con IA o machine learning.

Express

El framework más popular de Node. Muy simple: rutas y middlewares (funciones que se ejecutan en cadena antes de tu ruta). El resto lo agregás con paquetes de npm.

Explicado fácil: el Flask de Node. Una caja con lo justo, y como lo usa todo el mundo, hay un tutorial para cualquier cosa que quieras hacer.

import express from "express";
const app = express();

app.get("/hola", (req, res) => {
  res.json({ mensaje: "Hola" });
});

app.listen(3000);

Usalo para: APIs simples, aprender, proyectos donde querés control total.

Fastify

Muy parecido a Express, pero más rápido y con validación de datos incluida mediante schemas.

Explicado fácil: el mismo auto que Express, pero con mejor motor y con cinturón de seguridad de fábrica.

import Fastify from "fastify";
const app = Fastify();

app.get("/hola", async () => ({ mensaje: "Hola" }));

await app.listen({ port: 3000 });

Usalo para: APIs con mucho tráfico donde importa el rendimiento.

NestJS

Un framework con reglas claras: todo se organiza en módulos, controladores (reciben requests) y servicios (lógica). Usa TypeScript, decoradores e inyección de dependencias. Se parece a Angular o a Spring de Java.

Explicado fácil: una empresa con organigrama. Cada cosa tiene su departamento y su lugar. Al principio parece mucha burocracia, pero con 20 personas trabajando todos saben dónde va cada cosa.

@Controller("productos")
export class ProductosController {
  constructor(private service: ProductosService) {}

  @Get()
  listar() {
    return this.service.todos();
  }
}

Usalo para: backends grandes, equipos de varias personas, proyectos que van a durar años.

Next.js

Un framework de React que hace frontend y backend en el mismo proyecto. Cada archivo dentro de la carpeta app es una página, y puede leer la base de datos directamente. Soporta SSR, SSG e ISR.

Explicado fácil: un local que es cocina y salón a la vez. No necesitás un restaurante aparte para cocinar: todo pasa en el mismo lugar.

// app/productos/page.tsx → la URL /productos
export default async function Page() {
  const productos = await db.producto.findMany();
  return <ul>{productos.map(p => <li>{p.nombre}</li>)}</ul>;
}

Usalo para: sitios con SEO, e-commerce, SaaS, cuando el equipo ya sabe React.

Hono

Un framework muy chico y rápido que funciona igual en Node, Bun, Deno, Cloudflare Workers y Vercel.

Explicado fácil: un food truck. Liviano, lo llevás a cualquier lugar y arranca al toque.

import { Hono } from "hono";
const app = new Hono();

app.get("/hola", (c) => c.json({ mensaje: "Hola" }));

export default app;

Usalo para: APIs serverless o en el edge, webhooks, microservicios chicos.

Vertical vs horizontal

Vertical: máquina más grande. Simple, tiene techo. Horizontal: más máquinas detrás de un balanceador. Requiere que la app sea stateless: las sesiones van a Redis o a un JWT, los archivos a S3, nunca al disco local.

Caché en capas

Navegador (Cache-Control) → CDN → caché de aplicación (Redis) → caché de la DB. Patrones: cache-aside (leo caché, si no hay voy a DB y guardo), write-through. Lo difícil es invalidar.

Base de datos

Índices y queries primero. Después connection pooling (PgBouncer), réplicas de lectura, particionado de tablas grandes y, como último recurso, sharding (repartir datos por clave entre varias bases).

Colas y trabajo asíncrono

Lo que no necesita respuesta inmediata va a una cola: mails, PDFs, procesar imágenes, llamar a terceros. El request responde en milisegundos y un worker hace el resto.

Resiliencia

Timeouts en toda llamada externa, reintentos con backoff exponencial, circuit breaker para no saturar un servicio caído, health checks y degradación elegante.

Observabilidad

Los tres pilares: logs estructurados, métricas (latencia p95/p99, tasa de error, throughput) y traces distribuidos (OpenTelemetry). Sin esto, los microservicios son imposibles de operar.