Fundamentos de diseño de sistemas.
Un curso práctico, en español, para diseñar sistemas que crecen y aguantan fallas: requisitos y estimación, datos, replicación, colas, APIs y operación. Con una app de domicilios que crece de una ciudad a varios países.
PRÓXIMA COHORTE: POR ANUNCIAR
Diseña con números, no con intuición.
Seis habilidades para decidir cómo se construye un sistema: qué necesita, cómo guarda sus datos, qué hace cuando algo falla y cómo se opera.
Definir requisitos y estimar
- Requisitos no funcionales con números.
- QPS, almacenamiento y costo antes de diseñar.
- Qué problema resuelve cada pieza.
Modelar y guardar datos
- El modelo correcto para cada dato.
- Cómo funcionan los índices y los motores.
- Cambiar un esquema sin detener el servicio.
Distribuir los datos
- Réplicas y su retraso.
- Particiones, claves y hotspots.
- Aislamiento y anomalías de concurrencia.
Diseñar para las fallas
- Timeouts, reintentos e idempotencia.
- Consistencia y consenso sin mitos.
- Cortar una falla en cascada.
Conectar servicios
- APIs que otros equipos pueden usar.
- Monolito modular o microservicios.
- Sagas, outbox y eventos.
Operar y decidir
- SLO, presupuesto de errores y observabilidad.
- Despliegues que no rompen nada.
- Decisiones escritas que el equipo entiende.
Seis sesiones, una app que crece.
Cada sesión en vivo cubre tres bloques y termina con un proyecto sobre la app de domicilios. Entre sesiones, practicas con los casos clásicos: acortador de URLs, rate limiter, notificaciones, feed y chat.
Requisitos, estimación y el mapa de escala
Requisitos antes de dibujar
- Funcionales y no funcionales: qué hace el sistema y qué tan bien lo hace.
- Latencia p50 y p99, throughput y disponibilidad, con números.
- Costo y complejidad como requisitos, no como consecuencias.
- Las preguntas que acotan un problema ambiguo.
Cálculos rápidos
- Las latencias que todo ingeniero debe conocer: memoria, disco y red.
- De usuarios activos a QPS promedio y pico.
- Almacenamiento y ancho de banda a 1 y a 5 años.
- Los nueves de disponibilidad: cuántos minutos al mes es 99,9 %.
De un servidor a millones
- El camino de una petición: DNS, balanceador y servidor.
- Crecer en la misma máquina o agregar máquinas, y servidores sin estado.
- Réplicas de lectura, caché y CDN.
- Qué problema resuelve cada pieza, y qué problema nuevo trae.
Proyecto: La app de domicilios, versión 1 a 5
- Estima usuarios, pedidos y QPS de la app en una ciudad.
- Dibuja la versión 1: un servidor y una base de datos.
- Agrega una pieza por versión hasta llegar a la 5.
- Escribe qué problema resolvió cada salto.
Modelar y guardar datos
Modelos de datos
- Relacional, documentos y grafos: cuándo usar cada uno.
- Normalizar o desnormalizar, según cómo se leen los datos.
- Relaciones uno a muchos y muchos a muchos.
- Búsqueda de texto y datos geográficos.
Cómo guarda una base de datos
- Índices B-tree y LSM: qué optimiza cada uno.
- OLTP y OLAP: las transacciones y el análisis no se guardan igual.
- Almacenamiento por filas y por columnas.
- Leer un plan de consulta.
Codificación y evolución
- JSON, Protobuf y Avro.
- Compatibilidad hacia atrás y hacia adelante.
- Migraciones de esquema sin detener el servicio.
- Versionar los datos que viajan entre servicios.
Proyecto: Los datos de la app
- Modela pedidos, restaurantes, repartidores y menús.
- Decide dónde vive cada dato y por qué.
- Diseña los índices de las tres consultas más frecuentes.
- Planea una migración sin tiempo fuera de servicio.
Datos distribuidos
Replicación
- Un líder, varios líderes o ninguno.
- Replicación síncrona o asíncrona.
- Retraso de las réplicas: leer lo que escribí y lecturas monotónicas.
- Failover, y lo que se puede perder en él.
Particionamiento
- Por rango o por hash, y cómo elegir la clave.
- Hashing consistente y rebalanceo.
- Hotspots: el restaurante que todos piden a la misma hora.
- Índices secundarios sobre datos particionados.
Transacciones
- ACID sin marketing.
- Niveles de aislamiento y sus anomalías: lost update y write skew.
- Locks o control optimista.
- Transacciones entre servicios, y por qué evitar 2PC.
Proyecto: Pedidos en varias ciudades
- Particiona los pedidos y justifica la clave.
- Decide qué lecturas pueden venir de una réplica.
- Encuentra una anomalía de concurrencia y corrígela.
- Planea qué pasa si cae el líder.
Cuando las cosas fallan
Fallas parciales
- La red pierde, demora y duplica mensajes.
- Timeouts: cuánto esperar y qué hacer después.
- Relojes que no coinciden, y por qué no ordenar eventos por la hora.
- Detectar un nodo caído sin equivocarse.
Consistencia y consenso
- Consistencia linealizable, causal y eventual.
- CAP y PACELC sin mitos.
- Consenso con Raft y elección de líder.
- Locks distribuidos con fencing tokens, en etcd o ZooKeeper.
Resiliencia
- Reintentos con backoff y jitter.
- Idempotencia de punta a punta.
- Circuit breaker, backpressure y descarte de carga.
- Cómo nace una falla en cascada, y cómo se corta.
Proyecto: Un cobro que no se duplica
- Traza qué pasa si el pago tarda, falla o responde dos veces.
- Diseña la clave de idempotencia.
- Decide timeouts, reintentos y circuit breaker.
- Demuestra con un diagrama de secuencia que no hay doble cobro.
Servicios, APIs y eventos
APIs
- REST, gRPC y eventos: cuándo usar cada uno.
- Paginación, versionado y errores.
- API gateway, rate limiting y descubrimiento de servicios.
- Contratos entre equipos.
Monolito o microservicios
- Empezar con un monolito modular.
- Separar servicios por capacidad del negocio.
- Una base de datos por servicio.
- Migrar poco a poco con el patrón strangler.
Eventos y flujos de datos
- Colas y logs: RabbitMQ o Kafka.
- Sagas, outbox y CDC.
- CQRS y event sourcing: cuándo valen la pena.
- Procesamiento por lotes y en streaming.
Proyecto: El checkout como saga
- Divide el checkout en pedido, pago e inventario.
- Coordina los pasos con una saga.
- Publica los eventos con un outbox.
- Compensa cuando un paso falla.
Operar y decidir
Confiabilidad medida
- SLI, SLO y presupuesto de errores.
- Logs, métricas y trazas distribuidas.
- Alertas por síntomas, no por causas.
- Incidentes y postmortems sin culpables.
Cambiar sin romper
- Canary, blue-green y feature flags.
- Varias regiones: activo-pasivo y activo-activo.
- Seguridad básica: autenticación, autorización, secretos y cifrado.
- El costo como requisito del diseño.
Decidir en equipo
- ADR: registrar cada decisión y sus alternativas.
- Un método en cuatro pasos para presentar un diseño.
- Revisar el diseño de otro con preguntas útiles.
- El mismo método en una entrevista.
Proyecto: El diseño completo, defendido
- Define los SLO de la app.
- Escribe tres ADR de tus decisiones más difíciles.
- Presenta el diseño al grupo en 20 minutos.
- Responde las preguntas de los demás.
Tu app de domicilios, lista para escalar.
Cada semana le sumas una capa al mismo diseño. Al final tienes un sistema documentado, con sus números y sus decisiones, que puedes mostrar en tu equipo o en una entrevista.
Requisitos
La estimación de carga, los requisitos no funcionales y los SLO.
Datos
El modelo, los índices, las réplicas y las particiones.
Fallas
Idempotencia, reintentos y resiliencia en cada llamada crítica.
Decisiones
Los ADR de tus decisiones y la defensa del diseño ante el grupo.
Aprende de quien diseña y opera sistemas.
Victor Hazbun
Fundador · Bonsai LabsVictor construye software desde 2014. Trabajó como contratista para Priceline y GoDaddy, y como líder técnico formó a desarrolladores con sesiones en pareja, revisiones de código y planes de estudio. Desde 2023 diseña y opera sistemas de IA en producción: agentes, RAG, guardrails y evaluaciones. Hoy dirige Bonsai Labs, donde construye UTMKit y CodeWarden. En este curso enseña cómo decide la arquitectura de esos sistemas.
Qué necesitas antes de empezar
- Haber construido una app web con base de datos, en cualquier lenguaje.
- No hace falta experiencia con sistemas distribuidos ni con la nube.
- Un navegador: los diagramas se hacen en Excalidraw.
Qué recibes al inscribirte
- Seis sesiones en vivo con preguntas y respuestas.
- Grabación de cada sesión.
- Los diagramas del curso en Excalidraw, para reutilizarlos.
- Una comunidad con tu cohorte para avanzar en grupo.
- Horas de consulta opcionales sobre el material o tu proyecto.
- Certificado de finalización para tu perfil de LinkedIn.
Antes de inscribirte.
¿El curso es en español?
Sí. Las sesiones, los materiales y los proyectos están en español. Muchos términos técnicos están en inglés, y te explicamos cada uno.
¿El curso es en línea?
Sí. Todas las sesiones son en vivo y en línea: te conectas desde Colombia o desde cualquier otro país.
¿Qué necesito saber antes?
Haber construido una app web con base de datos, en cualquier lenguaje. No hace falta experiencia con sistemas distribuidos ni con la nube.
¿Tengo que programar?
No. Los proyectos son diseños: diagramas en Excalidraw, estimaciones y decisiones escritas. Si quieres, puedes llevarlos a código.
¿Cuánto tiempo necesito?
Son seis sesiones en vivo de 3 horas, una por semana. Con los proyectos, calcula entre 3 y 5 horas por semana.
¿Qué pasa si no puedo ir a una sesión?
Todas las sesiones se graban. Puedes verlas cuando quieras y seguir con los proyectos igual que el resto de la cohorte.
¿Me sirve para entrevistas?
Sí. La sesión 6 enseña un método para presentar y defender un diseño. Los casos clásicos de entrevista (acortador de URLs, rate limiter, notificaciones, feed y chat) quedan como práctica en la comunidad.
¿En qué se diferencia de «Construye sistemas IA para producción»?
Este curso enseña a diseñar cualquier sistema que escala. Construye sistemas IA para producción aplica esas ideas a sistemas de IA: modelos, RAG, evaluaciones y agentes.
¿Mi empresa puede pagar el curso?
Sí. Te enviamos una factura para que la presentes a tu presupuesto de formación.
¿Tienes otra pregunta?
Escríbenos a contact@bonsailabs.io.
Diseña hoy el sistema que vas a necesitar mañana.
Estamos definiendo la fecha y el precio de la primera cohorte. Escríbenos y te avisamos antes de abrir las inscripciones.