System Design
Reúne antipatrones como empezar por tecnologías, diseñar escala imaginaria, ignorar fallos, mezclar niveles, ocultar supuestos y producir documentación sin propósito.
Un antipatrón no es una práctica “prohibida”. Es una solución que parece razonable, se repite y falla porque ignora contexto, evidencia o consecuencias.
Reconocer antipatrones permite detener decisiones que generan complejidad sin reducir riesgo. La alternativa correcta no es otra receta universal, sino volver a drivers, restricciones y evidencia.
“Usaremos microservicios, Kafka y Kubernetes”Problema: la tecnología aparece antes del problema, la escala, el equipo y las garantías.
Señales:
Corrección:
Una restricción tecnológica real sí puede aparecer temprano, pero debe documentarse como restricción.
Diseñar para una escala hipotética crea colas, cachés, particiones y servicios que el equipo todavía no puede operar.
Diagnóstico:
Corrección: escala por evidencia, identifica hotspots reales y agrega complejidad de forma reversible.
“El sistema debe ser rápido, seguro y escalable.”No existe condición verificable.
Corrección:
El 95 % de las búsquedas responde en menos de 300 ms
con 150 solicitudes por segundo
sobre 100 000 productos.“Login, dashboard, productos y reportes” no explica resultados, responsabilidades ni fallos.
Corrección: expresar capacidades, actores, flujos, fuentes de verdad, integraciones y exclusiones.
La plantilla “como, quiero, para” no contiene reglas, errores, datos ni calidad.
Corrección: acompañar con conversación, criterios, reglas y trazabilidad.
“Presionar Guardar” es interacción de interfaz, no objetivo del actor.
Corrección: modelar “Registrar venta”, “Cancelar pedido” o “Aprobar transferencia”.
El diseño parece correcto hasta que existe timeout, duplicado, concurrencia o fallo parcial.
Corrección: para cada flujo incluir:
Mezcla usuarios, servicios, clases, bases, regiones y secuencias.
Consecuencia: nadie sabe qué pregunta responde.
Corrección: una vista por audiencia y nivel; Context, Container, Component, Sequence, State o ERD según la pregunta.
Una relación llamada “usa” oculta intención, protocolo, dirección y criticidad.
Corrección:
Order API → Inventory
Reserva unidades de forma síncrona por HTTPS
Timeout 300 ms; operación idempotenteCopiar tablas produce entidades anémicas y reglas dispersas.
Corrección: descubrir conceptos, identidad, invariantes y comportamiento antes de decidir persistencia.
User Service, Product Service y OrderLine Service suelen reflejar datos, no capacidades cohesionadas.
Consecuencia: transacciones distribuidas y llamadas excesivas.
Corrección: límites por responsabilidad, reglas y ritmo de cambio; mantener modularidad interna antes de distribuir.
Varios componentes escriben las mismas tablas directamente.
Consecuencia:
Corrección: ownership explícito, contratos y acceso controlado. Compartir infraestructura no implica compartir autoridad.
Cache, índice y proyección se actualizan sin estrategia de reconciliación.
Corrección: declarar autoridad, mecanismo de propagación, tolerancia al retraso y reparación.
isPaid
isCancelled
isDeliveredPermite combinaciones contradictorias.
Corrección: ciclo de vida explícito, transiciones, guards y efectos.
Retries sin límite multiplican carga y duplican efectos.
Corrección:
Muchos sistemas entregan al menos una vez y requieren consumidores idempotentes.
Corrección: definir exactamente qué efecto debe ser único, usar claves, deduplicación, transacción y reconciliación.
Añadir cache antes de medir puede ocultar consultas malas y crear invalidación compleja.
Corrección: perfilar, optimizar acceso, definir freshness y decidir qué ocurre ante miss o datos antiguos.
Se implementa autenticación, pero no autorización por recurso, tenant ni acción.
Corrección: threat modeling, límites de confianza, clasificación de datos, least privilege y pruebas desde el diseño.
Logs sin contexto no explican una solicitud ni el impacto al usuario.
Corrección: SLIs, correlation IDs, métricas de dominio, trazas y alertas accionables.
Tener archivos de backup no demuestra recuperación.
Corrección: ejecutar restore, medir RTO/RPO, validar integridad y documentar procedimiento.
Pesos arbitrarios y puntuaciones sin evidencia producen un ganador matemático falso.
Corrección: criterios ligados a drivers, restricciones eliminatorias, sensibilidad y evidencia.
Un spike omite seguridad, operación y mantenibilidad; una demo exitosa se presenta como producto listo.
Corrección: decidir si es desechable, registrar qué no demuestra y reconstruir garantías antes de producción.
Se escribe después para defender una decisión ya tomada.
Corrección: documentar contexto, alternativas y consecuencias mientras la decisión sigue abierta o al menos preservar honestamente la razón real.
Crear todos los diagramas aunque no reduzcan incertidumbre.
Corrección: cada artefacto debe tener pregunta, audiencia, owner y decisión asociada.
Páginas marcadas como listas no cambian aunque el sistema sí.
Corrección: fuente de verdad, estados, fechas, triggers, ownership y archivo de contenido sustituido.
Una recomendación externa sustituye análisis contextual.
Corrección:
driver
→ alternativa
→ consecuencia
→ evidencia
→ decisiónSe elige una solución costosa de operar para un problema aún no demostrado.
Corrección: priorizar decisiones reversibles, POC y medición antes de comprometer arquitectura.
Ante un diseño sospechoso pregunta:
Modelo mental completo de System Design integra la ruta correcta para evitar estos atajos.