Introducción: Consumidores idempotentes
Inbox Pattern protege a los consumidores contra mensajes duplicados.
Cuando llega un mensaje, primero se registra en una tabla Inbox. Si ya existe, se descarta; si no, se procesa.
Esto permite reintentos seguros sin efectos secundarios duplicados.
Prompt: Inbox table and deduplication, clean minimal style.
1. Naturaleza: Registro de entradas
Un edificio registra quién entra para evitar duplicados o accesos indebidos.
Si alguien intenta entrar dos veces con el mismo pase, se detecta y se evita el error.
Prompt: Entry logbook, soft illustration.
2. Mundo Real: Recepción de paquetes
Un almacén registra cada paquete recibido con un número único.
Si el transportista intenta entregar el mismo paquete dos veces, el sistema lo rechaza.
En mensajería, el Inbox evita que el consumidor ejecute la misma operación más de una vez.
Prompt: Warehouse receiving packages, clean flat style.
3. Implementación en C#: Código Paso a Paso
public class InboxMessage
{
public Guid Id { get; set; }
public DateTime ProcessedAt { get; set; }
}
bool AlreadyProcessed(Guid messageId)
{
// Consultar tabla Inbox
return false;
}Primero se consulta la Inbox. Si no existe, se procesa y se guarda el Id.
La combinación Inbox + Outbox es muy común para flujos confiables.
4. Inbox vs Retries sin control
Reintentar sin Inbox puede ejecutar la misma acción varias veces.
Inbox garantiza idempotencia y evita estados inconsistentes.
5. Diagrama UML
Prompt: UML diagram of Inbox pattern, clean vector layout.
Prompt: Inbox deduplication flow diagram, minimal infographic style.
⚠️ Cuándo NO Usar Inbox
- Si los mensajes no se reintentan ni se duplican.
- Si el costo de almacenamiento adicional es prohibitivo.
- Si las operaciones son naturalmente idempotentes.
💪 Ejercicio
Implementa un consumidor con Inbox que descarte mensajes duplicados y registre el resultado.
Conclusión
Inbox aporta seguridad frente a duplicados y fallos de red.
Con este patrón, los consumidores se vuelven predecibles y confiables.