01 / Entender
Arquitecturas y sus intercambios.
02 / Decidir
Preguntas que cambian el diseño.
03 / Publicar
Servicios, servidores y operación.
Arquitecturas y diseño de sistemas01
De una idea a una app online.
Cómo organizar una aplicación, elegir sus piezas y publicarla con criterio.
Una buena arquitectura responde a un problema concreto.
01 / Fundamentos02
¿Qué es una arquitectura?
Es la organización del sistema: sus partes, sus responsabilidades y cómo se comunican.
Usuario
→Aplicación
→Datos
Partes
Interfaz, lógica, datos e integraciones.
Relaciones
Quién llama a quién y qué información intercambian.
Decisiones
Qué priorizamos y qué costo aceptamos.
No es solo un dibujo: también son límites y decisiones.
Fundamentos03
Las piezas de una aplicación
Primero separa responsabilidades. Después decide dónde ejecutarlas.
Interfaz
→API
→Base de datos
Frontend
La interfaz que ve y usa la persona: una web, una app o un juego.
Backend / API
La lógica y los endpoints que reciben solicitudes y devuelven respuestas.
Almacenamiento
Lo que debe durar: registros en una base de datos y archivos en un storage.
API = una forma definida de pedirle algo a otro componente.
Fundamentos04
Una solicitud, de principio a fin
Ejemplo: guardar el progreso de un jugador.
Jugador
→POST /progreso
→Validación
→Datos
1. Pedir
El cliente envía el progreso y una credencial al endpoint.
2. Validar
El backend comprueba identidad, permisos y reglas del juego.
3. Responder
Guarda los datos y confirma el resultado, o devuelve un error.
El cliente no debe poder decidir por sí solo que tiene permisos.
Fundamentos05
Tres decisiones diferentes
El código, las máquinas y los datos no son lo mismo.
Código
Cómo separas las responsabilidades: capas, módulos o servicios.
Ejecución
Dónde corre cada parte: navegador, función, contenedor o servidor.
Datos
Quién es dueño de la información y cómo mantiene su consistencia.
Un monolito puede correr en un contenedor y usar una base administrada.
Arquitecturas06
Cliente y servidor
El cliente pide; el servidor procesa y responde.
Cliente
→Red / HTTP
→Servidor
Ventaja
Centraliza reglas y datos. Puedes actualizar el servidor sin reinstalar cada cliente.
Costo
Depende de la red. Debes manejar latencia, errores y disponibilidad.
Cuándo / ejemplo
Apps web y juegos online: un cliente consulta su perfil a una API.
Arquitecturas07
Monolito
Una aplicación reúne la lógica y se despliega como una unidad.
Interfaz
→Una aplicación
→Base de datos
Ventaja
Arranque sencillo, menos piezas y fácil seguimiento de una solicitud.
Costo
Cambios y despliegues comparten la misma aplicación; el acoplamiento puede crecer.
Cuándo / ejemplo
MVP y equipos pequeños: catálogo, pedidos y usuarios en un backend.
Monolito no significa código desordenado.
Arquitecturas08
Arquitectura por capas
Cada capa tiene una responsabilidad y usa interfaces para comunicarse.
Presentación
→Negocio
→Persistencia
Ventaja
Separa presentación, reglas y acceso a datos; facilita pruebas y mantenimiento.
Costo
Capas innecesarias agregan pasos. Si filtras detalles entre ellas, pierdes la separación.
Cuándo / ejemplo
Sistemas con reglas claras: una API llama a negocio y negocio a persistencia.
Capas lógicas ≠ máquinas distintas. Pueden vivir en un monolito.
Arquitecturas09
Monolito modular
Un despliegue, con módulos que tienen límites explícitos.
Usuarios
→Catálogo
→Pedidos
Ventaja
Conserva una operación sencilla y organiza el dominio en piezas claras.
Costo
Hay que cuidar los límites; importar todo desde cualquier módulo los rompe.
Cuándo / ejemplo
Producto que crece con un equipo pequeño. Shopify ha documentado este enfoque.
El diagrama es didáctico: muestra módulos dentro de una sola aplicación.
Arquitecturas10
Backend como servicio · BaaS
Usas servicios preparados para datos, identidad y archivos.
Frontend
→Auth / API
→Datos / archivos
Ventaja
Construyes antes: menos infraestructura y funcionalidades comunes listas.
Costo
Dependes de límites y APIs del proveedor. Los permisos siguen siendo tu responsabilidad.
Cuándo / ejemplo
Prototipos y apps CRUD: frontend + Supabase Auth, Postgres y Storage.
CRUD = crear, leer, actualizar y borrar registros.
Arquitecturas11
Funciones serverless
Tu código responde a solicitudes o eventos; la plataforma gestiona la ejecución.
Solicitud / evento
→Función
→Servicio de datos
Ventaja
Reduce la administración de servidores y puede escalar con la demanda.
Costo
Límites de ejecución, arranque y dependencia del proveedor. Revisa el modelo de cobro.
Cuándo / ejemplo
Webhooks, una API breve o procesar una imagen al subirla: AWS Lambda Functions.
Serverless sigue usando servidores: la plataforma se encarga de ellos.
Arquitecturas12
Microservicios
Servicios independientes, organizados por capacidades del negocio.
Usuarios / API
→Pedidos / API
→Pagos / API
Ventaja
Equipos pueden desplegar y escalar capacidades con mayor independencia.
Costo
Red, coordinación de datos, versiones y observabilidad hacen más difícil la operación.
Cuándo / ejemplo
Varios equipos con límites claros. Netflix documenta una arquitectura de microservicios.
Separar procesos no elimina el acoplamiento: también importan los contratos.
Arquitecturas13
Arquitectura por eventos
Una parte publica algo que ocurrió; otras reaccionan.
Pedido creado
→Cola / canal
→Consumidores
Ventaja
Desacopla trabajos y permite procesarlos en segundo plano.
Costo
Puede haber retrasos, duplicados y desorden. Necesitas reintentos y seguimiento.
Cuándo / ejemplo
Un pedido creado dispara correo, inventario y analítica mediante una cola.
Un evento dice lo que ocurrió. Un comando pide que ocurra algo.
Comunicación14
¿Esperar o continuar?
La comunicación síncrona y la asíncrona resuelven necesidades diferentes.
Solicitud
→Respuesta inmediata o trabajo pendiente
Síncrona
Pides y esperas la respuesta. Ejemplo: consultar el saldo antes de mostrarlo.
Asíncrona
Aceptas el trabajo y lo procesas después. Ejemplo: generar un reporte pesado.
La decisión
¿La persona necesita el resultado ahora? ¿Qué pasa si el trabajo falla después?
Comunicación15
Reintentar sin duplicar
Una solicitud puede llegar dos veces aunque el usuario haya hecho un solo clic.
Operación #123
→¿Ya existe?
→Mismo resultado
El problema
Se guarda un pedido, falla la respuesta y el cliente vuelve a intentarlo.
La solución
Usa un identificador de operación y reconoce si ya la procesaste: idempotencia.
La operación
Limita los reintentos, espera entre ellos y conserva los fallos para revisarlos.
No supongas que una cola o la red entregan todo exactamente una vez.
Arquitecturas16
Los patrones se combinan
No tienes que escoger una sola etiqueta para toda la aplicación.
API / monolito
→Base de datos
→Cola → función
Organización
Un monolito modular con capas para las reglas de negocio.
Ejecución
La API en un servidor; una función para procesar archivos.
Comunicación
HTTP para leer datos y eventos para tareas en segundo plano.
Explica qué problema resuelve cada pieza.
02 / Elegir17
Empieza por las restricciones
Antes del diagrama: entiende el producto y al equipo.
Producto
¿Qué debe hacer hoy? ¿Qué funciones son esenciales para la primera versión?
Equipo
¿Cuántas personas construyen y operan? ¿Qué tecnologías conocen?
Recursos
¿Cuánto pueden gastar y cuánto tiempo tienen para lanzar?
Para una app sencilla, empieza evaluando un monolito modular o un BaaS.
Preguntas de un senior18
Producto y personas
Las respuestas pueden cambiar la arquitectura más que una preferencia técnica.
Usuarios
¿Quién usa el sistema, desde dónde y con qué conexión? ¿Cuáles son los picos?
Trabajo
¿Qué recorrido es crítico? ¿Necesita respuesta inmediata o puede esperar?
Equipo
¿Quién despliega y atiende fallos? ¿Necesitamos que varios equipos publiquen por separado?
Preguntas de un senior19
Datos y fallos
Diseña lo que ocurre cuando algo sale mal.
Datos
¿Qué es sensible? ¿Dónde debe almacenarse? ¿Qué no puede perderse ni duplicarse?
Consistencia
¿Todos deben ver el mismo estado inmediatamente? ¿Se tolera un retraso?
Recuperación
¿Cuánto tiempo podemos estar caídos? ¿Cuántos datos podemos perder? ¿Cómo restauramos?
Pregunta por el impacto del fallo, no solo por la cantidad de usuarios.
Elegir20
Convierte deseos en objetivos
Ejemplo de requisitos para un ejercicio; estos números no son recomendaciones universales.
Rendimiento
El 95 % de las consultas de perfil responde en menos de 500 ms.
Recuperación
Restaurar el servicio en 1 hora; perder como máximo 24 horas de datos.
Costo
Un presupuesto mensual acordado, con alertas y revisión del consumo.
Un objetivo medible permite probar si el diseño cumple.
Elegir21
Registra la decisión · ADR
Un documento corto conserva el porqué de una elección.
Contexto
Equipo de dos personas; necesitamos cuentas, perfiles y una primera versión web.
Decisión
Vercel + Supabase. Alternativa: API propia + Postgres en un VPS.
Consecuencia
Lanzamos pronto; aceptamos dependencia del proveedor y revisaremos límites y costo.
Incluye una señal para revisarla: límites, costos o nuevas necesidades.
Evolución22
Escala lo que realmente limita
Primero mide: CPU, memoria, consultas, tiempos y errores.
Medir
→Encontrar el cuello
→Cambiar y comprobar
Optimizar
Corrige consultas, índices o trabajo repetido antes de multiplicar servidores.
Vertical
Una máquina con más capacidad. Sencillo, pero tiene un techo.
Horizontal
Varias instancias distribuyen trabajo. Requiere coordinar tráfico y estado.
Más usuarios no significa automáticamente microservicios.
Evolución23
El estado debe sobrevivir
Si una instancia desaparece, la información importante no debería desaparecer con ella.
Instancia A / B
→Datos compartidos
→Almacenamiento durable
Proceso
Memoria y disco local pueden ser temporales. No guardes ahí la única copia del progreso.
Persistencia
Datos en una base; archivos en storage; sesiones compartidas cuando sea necesario.
Instancias
Con estado externo, varias instancias pueden atender solicitudes del mismo usuario.
Stateless: una instancia no necesita recordar solicitudes anteriores para atender la próxima.
03 / Publicar24
De localhost a internet
Tu máquina puede servir la app mientras está encendida; publicar requiere una dirección accesible y una operación estable.
Código
→Build
→Deploy
→URL pública
Construir
Generas los archivos o la imagen ejecutable de la aplicación.
Desplegar
Los colocas en una plataforma o servidor conectado a internet.
Conectar
Configuras dominio, HTTPS, variables, datos y servicios externos.
Publicar la interfaz no publica automáticamente el backend ni la base de datos.
Publicar25
Estático o dinámico
Esta diferencia ayuda a elegir dónde alojar cada pieza.
Navegador
→Archivos + API
→Datos
Estático
HTML, CSS, JavaScript e imágenes ya generados. Un hosting o CDN entrega archivos.
Dinámico
Código del servidor responde según el usuario o los datos: API y renderizado del servidor.
Combinado
Una interfaz estática puede llamar a una API dinámica. No necesitas alojarlas juntas.
Una app hecha con un framework no es necesariamente solo estática.
Publicar26
¿Quién administra qué?
Cuanto más control tomas, más operación asumes.
Plataforma
Gestiona gran parte de la infraestructura. Tú cuidas código, permisos, datos y consumo.
VPS
Recibes una máquina virtual. Tú configuras sistema, procesos, actualizaciones y backups.
Servidor físico
Puedes tener hardware exclusivo. Debes definir quién cuida red, hardware y sistema.
Administrado no significa libre de responsabilidades.
Servicios27
Vercel
Una ruta directa del repositorio a una web publicada.
Para qué
Frontend, sitios y aplicaciones con funciones del servidor compatibles con su plataforma.
Cómo
Conecta Git, configura el proyecto y las variables. Cada cambio puede generar un despliegue.
Qué revisar
Build, previews, runtime, límites y costo. Un proceso persistente de juego necesita otra evaluación.
Una preview permite probar un cambio antes de llevarlo a producción.
Servicios28
Supabase
Una base Postgres acompañada de servicios para construir una aplicación.
Datos
Postgres para registros relacionados: usuarios, perfiles, productos y pedidos.
Servicios
Auth para identidad; Storage para archivos; Realtime y Edge Functions según la necesidad.
Permisos
Configura políticas de acceso. Con RLS, cada fila tiene reglas sobre quién puede leerla o cambiarla.
RLS = seguridad a nivel de fila. Tener login no define todos los permisos.
Receta29
Una primera app online
Vercel + Supabase: una combinación para una app web con cuentas y datos.
Usuario
→Web / Vercel
→Auth + datos / Supabase
1 / Interfaz
Publica el frontend en Vercel y configura la URL del proyecto.
2 / Datos
Crea tablas, Auth y políticas RLS en Supabase; usa Storage para los archivos.
3 / Lógica sensible
Ejecuta operaciones privilegiadas en backend o funciones; conserva allí los secretos.
Prueba con dos cuentas: una no debe ver ni modificar los datos privados de la otra.
AWS / Primeras opciones30
Amplify o Lightsail
Dos puntos de entrada con responsabilidades diferentes.
Amplify Hosting
Publicación web con flujo desde Git, builds y distribución. Útil para frontends compatibles.
Lightsail
Instancias y recursos con una experiencia más simple que armar cada pieza por separado.
Cómo elegir
Si solo necesitas publicar una web, evalúa hosting. Si necesitas controlar una máquina, evalúa Lightsail.
AWS es un catálogo de servicios: empieza con las piezas que necesitas.
AWS / Cómputo31
EC2 o Lambda + API Gateway
Una máquina virtual frente a funciones que atienden solicitudes o eventos.
EC2
Control sobre una VM y sus procesos. Puedes alojar una API o un servidor persistente.
Lambda Functions
Ejecuta código por solicitudes o eventos; revisa tiempos, recursos y modelo de ejecución.
API Gateway
Expone endpoints y conecta solicitudes con un backend como Lambda.
EC2 exige más administración; las funciones exigen adaptarte a su runtime.
AWS / Archivos32
S3 + CloudFront
Almacenamiento de objetos y distribución de contenido.
S3
Guarda archivos como objetos: imágenes, videos, exportaciones y respaldos.
CloudFront
Una CDN distribuye contenido desde ubicaciones cercanas a los usuarios.
Ejemplo
Los avatares viven en S3 y se entregan mediante CloudFront; sus metadatos viven en una base.
S3 no sustituye a una base relacional ni ejecuta tu backend.
AWS / Datos33
RDS o DynamoDB
Elige según las consultas y relaciones que requiere tu aplicación.
RDS
Bases relacionales administradas. Útil para SQL, relaciones y transacciones.
DynamoDB
Base NoSQL de clave-valor y documentos. Diseña sus claves según los accesos previstos.
La pregunta
¿Cómo leerás y actualizarás los datos? No elijas solo por la promesa de escalar.
Administrado reduce trabajo operativo; todavía debes diseñar y proteger tus datos.
AWS / Apoyo34
Identidad, colas y señales
Tres servicios frecuentes alrededor de una aplicación.
Cognito
Registro e inicio de sesión. Tu aplicación sigue decidiendo qué puede hacer cada usuario.
SQS
Colas para trabajo en segundo plano. Diseña consumidores capaces de manejar reintentos.
CloudWatch
Logs, métricas y alarmas para entender qué ocurre y detectar fallos.
Añade cada servicio cuando resuelva una necesidad concreta.
Google Cloud35
Firebase y Cloud Run
Publicar una interfaz y ejecutar un backend administrado.
Firebase Hosting
Hosting para archivos web, con HTTPS y distribución. Útil para el frontend.
Cloud Run
Ejecuta contenedores en una plataforma administrada; permite publicar un servicio HTTP.
Alrededor
Auth, una base y almacenamiento de objetos según tus necesidades. Conserva los datos fuera del contenedor.
Un contenedor que arranca bien en local todavía necesita configuración y permisos en la nube.
Azure36
Webs, APIs y datos
Servicios administrados para cada responsabilidad.
Static Web Apps
Publica aplicaciones web con archivos estáticos e integración de backend según la configuración.
App Service
Aloja aplicaciones y APIs; admite distintos runtimes y contenedores compatibles.
Datos / archivos
Azure Database for PostgreSQL para datos relacionales; Blob Storage para objetos.
Escoge por requisitos, experiencia del equipo y costo de operar.
Una opción adicional37
Cloudflare
Archivos estáticos, código y almacenamiento dentro de otra plataforma.
Workers Static Assets
Publica los archivos de una web junto con un Worker cuando necesitas lógica.
Workers
Ejecuta código en el runtime de la plataforma. Revisa compatibilidad y límites.
R2
Almacenamiento de objetos para archivos. No reemplaza tu modelo de datos relacional.
Antes de migrar, verifica que tu aplicación sea compatible con el entorno de ejecución.
Servidores38
VPS · una máquina virtual
Un servidor virtual que puedes configurar para tu aplicación.
Internet
→VPS / proxy
→Aplicación
Ventaja
Control del sistema y los procesos; útil para backends y servicios persistentes.
Costo
Actualizaciones, seguridad, monitoreo, certificados, backups y recuperación.
Cuándo / ejemplo
API o servidor de juego con necesidades concretas. Un proveedor como DigitalOcean ofrece VMs.
CPU dedicada en una VM no implica un servidor físico completo para ti.
Servidores39
Servidor dedicado físico
Hardware reservado para un cliente; la administración depende del contrato.
Ventaja
Mayor control del hardware y capacidad exclusiva para cargas sostenidas.
Costo
Menos flexibilidad inmediata; debes prever fallos y quién mantiene el equipo.
Cuándo / ejemplo
Requisitos de hardware, aislamiento o consumo sostenido que justifican esa operación.
“Servidor dedicado de juego” también puede ser un proceso que corre en una VM.
Herramientas40
Docker: empaquetar la app
Una imagen contiene la aplicación y sus dependencias; un contenedor la ejecuta.
Código + dependencias
→Imagen
→Contenedor
Ventaja
Repite el entorno y facilita entregar la app a plataformas que aceptan contenedores.
Límite
No gestiona por sí solo dominio, escalado, backups ni toda la seguridad.
Datos
El contenedor se puede reemplazar. Usa volúmenes o servicios externos para persistir información.
Un contenedor comparte el kernel del host; no es una máquina virtual completa.
Despliegue41
Un recorrido que puedes repetir
Deja una ruta clara desde un cambio hasta una aplicación comprobada.
Git
→Build
→Configuración
→Deploy + prueba
Preparar
Repositorio, build reproducible, variables y migraciones de datos planificadas.
Publicar
Despliega una versión identificable y conecta los servicios necesarios.
Verificar
Abre la URL, inicia sesión, prueba el recorrido crítico y comprueba logs y errores.
Conserva una versión anterior que puedas volver a desplegar.
Despliegue42
Dominio, DNS y HTTPS
Una dirección fácil de recordar necesita apuntar al destino correcto.
miapp.com
→DNS
→Destino con HTTPS
Dominio
El nombre: por ejemplo, miapp.com. Se registra y renueva.
DNS
Indica a qué destino corresponde ese nombre mediante registros.
HTTPS
Cifra la conexión con un certificado válido; muchas plataformas lo gestionan.
Si el dominio abre la web pero falla la API, revisa también las URLs y la configuración del backend.
Seguridad43
Identidad, permisos y secretos
Son tres responsabilidades distintas.
Identidad
Autenticación: ¿quién eres? Un login o token demuestra una identidad.
Permisos
Autorización: ¿qué puedes hacer? Comprueba cada acción y cada acceso a datos.
Secretos
Claves privadas en el servidor. Una clave publishable de Supabase requiere RLS; service_role no va en el cliente.
Lo que incluyes en el JavaScript del navegador puede ser visto por el usuario.
Operación44
Publicada no significa terminada
El sistema necesita señales y una forma de recuperarse.
Observar
Logs para eventos, métricas para tendencias y alertas para problemas que requieren acción.
Recuperar
Backups y pruebas de restauración; versiones identificables y un plan de rollback.
Controlar costo
Revisa cómputo, almacenamiento y transferencia. Una alerta de presupuesto no es un tope automático.
Un respaldo que nunca has restaurado todavía no prueba que puedas recuperar el sistema.
Ejemplo / Videojuegos45
Una partida tiene otra exigencia
Guardar un perfil y simular una partida en tiempo real son trabajos diferentes.
Clientes
→Servidor de partida
→API + datos
Perfil / inventario
Una API y una base persistente guardan información entre sesiones.
Partida
Un proceso autoritativo valida acciones y mantiene el estado compartido durante la sesión.
Hosting
Evalúa latencia, regiones, sesiones y capacidad. Amazon GameLift Servers es una opción especializada.
El proceso autoritativo decide el estado válido; el cliente envía acciones.
Errores frecuentes46
Tres errores que salen caros
La complejidad y los fallos suelen aparecer en decisiones pequeñas.
Separar demasiado pronto
Microservicios sin equipos ni necesidades independientes aumentan el trabajo de coordinación.
Confiar en el cliente
Ocultar un botón no protege una operación. El servidor o las políticas deben validarla.
Olvidar la recuperación
Disco local, secretos expuestos o backups sin pruebas pueden convertir un fallo en pérdida de datos.
La arquitectura incluye lo que pasa después del primer despliegue.
Para cerrar47
Diseña. Justifica. Publica.
Elige una app pequeña: perfiles de jugadores, una tienda o una lista de tareas.
Dibuja
Cliente, lógica y datos. Marca quién se comunica con quién y qué se guarda.
Justifica
Una opción, una alternativa, una ventaja y un costo. Añade una señal para evolucionar.
Publica
Elige servicios, protege permisos y secretos, y prueba un recorrido completo en una URL.
La mejor elección es la que puedes explicar, operar y comprobar.