System Design
Explica cómo usar prototipos, spikes y pruebas de concepto para reducir incertidumbre sobre tecnología, integración, rendimiento, experiencia y viabilidad.
Un prototipo o POC existe para responder una pregunta y reducir incertidumbre. Una demo que funciona una vez no demuestra seguridad, mantenibilidad, capacidad ni preparación para producción.
Los experimentos de diseño convierten supuestos y riesgos en evidencia. Deben tener hipótesis, alcance, datos, criterio de salida y decisión posterior.
Valida comprensión, flujo y usabilidad sin construir el sistema completo.
Permite probar consumidores antes de que exista el proveedor real.
Explora una tecnología o enfoque durante un timebox y produce aprendizaje documentado.
Modela comportamiento bajo condiciones difíciles de reproducir, como capacidad o colas.
Compara rendimiento de alternativas con carga y datos controlados.
Demuestra si una capacidad crítica parece viable dentro de condiciones explícitas.
Pregunta:
Hipótesis:
Riesgo o decisión relacionada:
Alcance y exclusiones:
Timebox:
Datos y entorno:
Qué se construirá:
Métrica:
Criterio de éxito y fracaso:
Limitaciones:
Resultado:
Decisión siguiente:¿Una actualización condicional en PostgreSQL evita sobreventa con 200 reservas concurrentes sobre el mismo producto?
Ninguna ejecución confirmada dejará reserved > on_hand y el p95 permanecerá debajo del umbral acordado.
Integridad preservada y comportamiento de conflicto comprensible. Si la latencia no cumple, probar batching, lock o rediseño del flujo.
No construyas una aplicación completa para probar una propiedad puntual.
Versiones, hardware, red, tamaño de datos y caché deben registrarse.
Un benchmark con 100 filas y datos uniformes no predice una tabla grande con skew.
Una sola ejecución puede beneficiarse de caché, ruido o casualidad.
Código, configuración, resultados y conclusiones deben poder revisarse.
Define ambos antes de ejecutar. De lo contrario, es fácil reinterpretar cualquier resultado como positivo.
Éxito: p95 < 300 ms y cero invariantes rotas.
Fracaso: inconsistencia, error > 1 % o necesidad de operación no disponible para el equipo.Un resultado negativo es valioso si elimina una alternativa costosa.
Optimiza aprendizaje. Puede omitir estructura, observabilidad y controles, pero esas omisiones deben ser explícitas.
Se construye con estándares cercanos a producción porque se espera continuar. Requiere mayor coste desde el inicio.
Nunca permitas que un prototipo desechable se convierta silenciosamente en sistema crítico.
Antes de promover un POC revisa:
“Funcionó en mi laptop” solo demuestra una condición muy limitada.
El prototipo puede demostrar que una persona entiende el flujo, pero no que la integración o capacidad funcionará. El POC técnico puede demostrar viabilidad, pero no que el producto sea útil. Pueden ser necesarios ambos.
Incluye:
Un happy path del SDK no valida la integración completa.
El experimento aprueba una alternativa que falla con distribución real.
Optimiza una operación y empeora otra más importante.
El criterio no estaba definido; se necesita rediseñar el experimento.
El spike se convierte en proyecto sin decisión. Detén al terminar el timebox y evalúa.
Pasos ocultos o datos precargados pueden dar una impresión falsa de automatización.
Trazabilidad del diseño conecta cada decisión y evidencia con la necesidad que la originó.