System Design
Escenarios e interacciones
Explica cómo describir escenarios concretos de colaboración entre actores, sistema y dependencias para revelar decisiones, datos, errores y garantías.
- Última actualización
- Actualizada
- Nivel
- Aplicación
System Design
Explica cómo describir escenarios concretos de colaboración entre actores, sistema y dependencias para revelar decisiones, datos, errores y garantías.
Un escenario convierte una capacidad abstracta en una historia temporal concreta: quién participa, qué estado existe, qué mensajes se intercambian, qué puede fallar y cómo termina el sistema.
Antes de dibujar componentes, conviene narrar una interacción específica.
estado inicial
→ trigger
→ participantes y mensajes
→ decisiones / fallos
→ estado final y evidenciaLos escenarios revelan responsabilidades y garantías que una lista de requisitos puede ocultar.
“Confirmar pedido” no explica:
Narrar el escenario permite discutir estas decisiones antes de convertirlas en endpoints o colas.
Alcanza el objetivo por el camino esperado.
Alcanza el objetivo mediante una variación válida: otro medio de pago, aprobación manual o disponibilidad parcial.
La operación no procede por una regla conocida: sin stock, fuera de horario o permiso insuficiente.
Una dependencia, red o proceso falla y exige recuperación.
Describe reintento, reconciliación, compensación o intervención humana.
Dos actores o eventos compiten por el mismo estado.
Nombre y objetivo:
Participantes:
Estado inicial:
Trigger:
Supuestos:
Interacciones:
Decisiones:
Timeouts y retries:
Estado final:
Evidencia observable:
Correlación e idempotencia:Usa responsabilidades del dominio:
Cliente → Pedidos → Inventario → PagosIntroduce frontend, API, base de datos, broker y proveedor.
Primero valida la lógica. Después asigna responsabilidades a componentes. Empezar por infraestructura puede esconder que una sola responsabilidad quedó repartida de forma incoherente.
El emisor espera respuesta. La dependencia entra en la ruta crítica de latencia y disponibilidad.
El emisor continúa y el resultado llega después. Reduce acoplamiento temporal, pero introduce:
La asincronía no elimina fallos; cambia dónde y cuándo se manejan.
Estado inicial:
- pedido draft
- stock disponible
- cliente autenticado
1. Cliente solicita confirmar.
2. Pedidos valida estructura, estado y permiso.
3. Inventario intenta reservar cantidades.
4. Pagos procesa el cobro.
5. Pedidos registra confirmación y referencia de pago.
6. Se publica OrderConfirmed.
7. Cliente recibe ID y estado confirmed.Estas preguntas son el valor del escenario.
1. Pedidos solicita pago con idempotency key.
2. La pasarela procesa, pero la respuesta excede el timeout.
3. Pedidos no sabe si existe cobro.
4. Conserva payment_pending y la reserva temporal.
5. Consulta o recibe webhook de reconciliación.
6. Si está approved, confirma una sola vez.
7. Si está rejected o expira, libera la reserva.Marcar directamente failed y reintentar podría duplicar cobros.
Pedido A y Pedido B solicitan 4 unidades.
Stock vendible: 5.
A y B llegan simultáneamente.
Inventario coordina la reserva.
Solo uno obtiene 4.
El otro recibe insuficiencia.
Stock nunca queda negativo.El escenario expresa la garantía sin imponer lock, serialización u optimismo.
Nombra mensajes por significado:
ReserveInventory
InventoryReserved
PaymentRequested
PaymentApprovedEvita nombres puramente técnicos como callService o sendData. Incluye información clave: identidad, versión, idempotency key y correlación cuando corresponda.
Sin estado inicial, una interacción puede parecer válida desde cualquier situación. Sin estado final, no sabes qué persistió.
Ejemplo:
Inicial: pedido confirmed, pago approved.
Final exitoso: pedido cancelled, refund_pending, stock liberado.
Final de fallo: pedido cancellation_pending con intervención programada.Todo llamado remoto necesita una expectativa temporal. El timeout no demuestra que la operación externa falló; solo que no se recibió respuesta a tiempo.
Define:
Un retry seguro exige:
Reintentar validaciones de negocio o errores permanentes solo aumenta carga.
En un flujo distribuido conserva:
request_id
correlation_id
causation_id
idempotency_key
external_referenceNo todos son obligatorios, pero deben distinguirse. La correlación permite seguir el escenario; la idempotencia evita repetir efectos.
Cuando no existe una transacción global, una acción posterior puede deshacer semánticamente una anterior:
reserva creada
→ pago rechazado
→ liberar reservaLa compensación también puede fallar. Modela reintento, estado pendiente y operación manual.
El consumidor reconoce el ID y evita efectos repetidos.
Decide guardar, ignorar, rechazar o reconciliar según versión y estado.
El flujo puede degradar, encolar o detenerse.
No debe sobrescribir un estado más nuevo sin control de versión.
Define carrera y punto de no retorno.
Conserva estado explícito y plan de recuperación.
Valida firma, origen y replay antes de confiar.
Produce diagramas que solo describen demos.
Un evento afirma un hecho; una llamada solicita una acción.
Añade complejidad de entrega y estado.
Duplican pagos, pedidos o notificaciones.
Primero identifica responsabilidades; no agregues broker por moda.
Separa nominal, timeout, cancelación y recuperación cuando la representación pierde claridad.
El sistema puede quedar internamente cambiado sin contrato visible.
Útil para integraciones, pagos, operaciones críticas, asincronía y flows con fallos. Para CRUD trivial puede bastar un criterio de aceptación.
Diagramas de secuencia representa visualmente participantes, mensajes, alternativas y tiempos de estos escenarios.