🎯 Qué entregas: documentos, no código. Es el proyecto que más se parece a lo que hace un ingeniero senior en su día a día y el que más directamente te prepara para una entrevista de diseño de sistemas.
Prerrequisitos: capítulos 23 a 26. Duración: ~1 semana (2-3 h por ejercicio).
⚠️ La tentación será escribir código. No lo hagas. Todo el valor de este proyecto está en obligarte a razonar sin poder esconderte detrás de la implementación. Cuando alguien no sabe diseñar, se pone a programar rápido para sentir que avanza. Aquí no hay esa salida.
Formato de entrega (para los cinco)
Cada ejercicio produce un documento de 2-4 páginas con esta estructura:
# Diseño · <nombre>
## 1. Preguntas de clarificación
Mínimo 8, con la RESPUESTA que asumes y por qué. Marca con ⭐ las 2 que más
cambiarían el diseño según la respuesta.
## 2. Requisitos
Funcionales (qué hace) · No funcionales (cómo de bien) · NO objetivos.
## 3. Estimaciones de servilleta
Peticiones/s media y pico · ratio lectura/escritura · almacenamiento a 3 años
· ancho de banda. Y la CONCLUSIÓN: ¿qué te dicen estos números?
## 4. Modelo de datos
Esquema con tipos e índices. Cada índice, justificado con su consulta.
## 5. Diseño
Diagrama + el flujo de las 2-3 operaciones principales, paso a paso.
## 6. El problema difícil
Todo diseño tiene UNO. Identifícalo y resuélvelo en detalle.
## 7. Alternativas descartadas
Al menos dos, con el motivo real.
## 8. Fallos
Qué pasa si cae cada componente. Qué ve el usuario en cada caso.
## 9. Evolución
Etapa 1 (lanzamiento) y la métrica concreta que dispara cada etapa siguiente.
## 10. ADR
El de la decisión más importante, con la plantilla del capítulo 25.Ejercicio 1 · Sistema de notificaciones multicanal
Notificaciones por email, SMS, push y dentro de la app. Los usuarios eligen qué reciben y por qué canal. 2 millones de usuarios, picos de 500.000 notificaciones en 10 minutos (envíos masivos). Las notificaciones críticas (seguridad, pagos) no se pueden perder.
El problema difícil: cómo garantizas que una notificación crítica llega, cuando dependes de proveedores externos que fallan, sin enviarla cinco veces.
Pistas de dirección: separa "crear la notificación" de "entregarla". Piensa en preferencias como datos, no como ifs. Un proveedor caído no puede bloquear los otros canales. Y pregúntate qué significa exactamente "no se puede perder": ¿reintentos indefinidos? ¿durante cuánto tiempo? ¿qué pasa si el email del usuario ya no existe?
Ejercicio 2 · Detección de fraude en tiempo real
Una pasarela de pagos debe decidir en menos de 100 ms si una transacción es sospechosa. Reglas configurables por el equipo antifraude (sin desplegar código) más un modelo de riesgo. 3.000 transacciones por segundo. Un falso positivo bloquea a un cliente legítimo; un falso negativo cuesta dinero.
El problema difícil: el presupuesto de 100 ms. ¿Qué datos necesitas y cómo los tienes disponibles a esa velocidad? (¿Cuántas transacciones hizo esta tarjeta en la última hora? ¿Desde cuántos países?)
Pistas: los agregados en ventana temporal no se calculan al vuelo con un COUNT(*). Piensa qué se precalcula, dónde vive y qué pasa si ese almacén se cae — ¿bloqueas todas las transacciones o dejas pasar todo? Esa decisión es de negocio, no técnica, y debes plantearla como tal.
Ejercicio 3 · Sistema de cupones y descuentos
Cupones con reglas: porcentaje o importe fijo, mínimo de compra, categorías aplicables, caducidad, límite global de usos, límite por usuario, combinables o no entre sí. Se usan en el checkout de un e-commerce con picos en Black Friday.
El problema difícil: un cupón con "solo 100 usos" y 5.000 personas intentando canjearlo en el mismo segundo. Ni uno de más. (Repasa el caso 1 del capítulo 26.)
Pistas: este ejercicio parece el más aburrido y es el más traicionero. El motor de reglas se convierte en un monstruo si lo modelas mal — piensa si las reglas son datos o código. Y ojo con el orden de aplicación cuando hay varios descuentos: ¿el 10% se aplica antes o después del cupón de 5 €? La respuesta cambia el importe final y tiene implicaciones contables.
Ejercicio 4 · Analítica de producto
Recoger eventos de uso (clics, vistas, conversiones) de una web y una app. 50.000 eventos por segundo. El equipo de producto consulta paneles con embudos, retención y segmentación sobre 12 meses de histórico. Las consultas deben responder en segundos.
El problema difícil: la tensión entre ingerir 50.000 escrituras/s y consultar agregados sobre miles de millones de filas. Son dos cargas de trabajo opuestas.
Pistas: este es el ejercicio donde PostgreSQL puede no ser la respuesta para todo, y donde debes justificarlo con números, no con moda. Investiga qué es una base de datos columnar y por qué existe. Piensa también en qué se puede precalcular: un embudo consultado 200 veces al día no debe recalcularse 200 veces.
Ejercicio 5 · Rediseña un sistema que ya conoces
Coge el proyecto P2 o P3 que construiste, o cualquier sistema con el que hayas trabajado. Rediséñalo para 100 veces más carga.
Entregables adicionales:
- Qué se rompe primero al multiplicar por 100, y cómo lo sabes (¿qué medirías?).
- Los tres cambios de mayor impacto, ordenados por relación beneficio/esfuerzo.
- Qué decisiones del diseño original resultaron ser de una vía (cap. 23) y cuánto costaría revertirlas ahora.
- Qué harías diferente si empezaras hoy, y qué mantendrías exactamente igual.
🧠 Este es el ejercicio más valioso de los cinco, porque es el único donde tienes contexto real y conoces las decisiones desde dentro. También es el más incómodo: vas a encontrar cosas que hiciste mal. Eso es exactamente la señal de que estás aprendiendo.
Autoevaluación de tus documentos
Repasa cada entregable con esta lista. Es dura a propósito:
□ ¿Hay al menos DOS alternativas descartadas con un motivo real (no "es peor")?
□ ¿Las estimaciones llevan a una CONCLUSIÓN, o son números sueltos?
□ ¿Identificaste el problema difícil, o describiste solo el camino feliz?
□ ¿Dijiste explícitamente qué NO vas a hacer?
□ ¿Cada índice tiene su consulta justificándolo?
□ ¿Explicaste qué ve el USUARIO cuando cada componente se cae?
□ ¿Hay alguna decisión que no sabrías defender si te preguntaran "¿por qué no X?"?
□ ¿Empezaste por la arquitectura más simple que cumple los requisitos,
o por la más impresionante?
□ ¿Tu diseño tiene piezas que no puedes justificar con un requisito concreto?⚠️ La última pregunta es la que más suspende gente. Si tu diseño incluye Kafka, Kubernetes y tres microservicios pero el enunciado son 5 escrituras por segundo, no has diseñado: has decorado. Un diseño excelente para este proyecto puede ser perfectamente "un servidor, una base de datos y una cola, y aquí están los números que demuestran que basta".
Cómo defender un diseño (y cómo se hacen estas entrevistas)
Si puedes, explícale uno de tus diseños a otra persona durante 20 minutos. El formato real:
0-2 min Repites el problema con tus palabras y haces PREGUNTAS.
⚠️ Empezar a dibujar cajas sin preguntar es el fallo nº1.
2-5 min Requisitos, no objetivos y estimaciones. En voz alta.
5-10 min El diseño de alto nivel. Empieza SIMPLE.
10-20 min Profundizas donde te pidan y evolucionas el diseño ante nuevas
restricciones ("¿y si ahora son 100× más usuarios?").
Siempre Razonas en voz alta y dices lo que NO sabes. "No he trabajado con
esto; mi intuición es X, lo verificaría midiendo Y" es una respuesta
excelente. Inventar con seguridad es la peor.Siguiente: 05-producto-propio.md