Se acepta un pedido, pero el sistema de almacén no está disponible durante un momento. Si todos los componentes posteriores deben responder inmediatamente, un problema temporal puede interrumpir todo el recorrido del cliente. La mensajería ofrece otra opción: registrar el trabajo pendiente y dejar que su responsable lo procese cuando pueda.
Azure Service Bus puede aportar esa comunicación, pero una cola cambia las preguntas que debe responder la aplicación. Hay que saber si se aceptó el trabajo, si ocurrió su efecto de negocio y qué queda pendiente. Un diseño fiable muestra esos estados, en lugar de trasladar la incertidumbre de la petición web a un proceso sin supervisión.
Describe el mensaje como un contrato de negocio
Elige si pide una acción o comunica un hecho ocurrido. «Reservar existencias» y «Pedido aprobado» tienen significados y responsables diferentes. El receptor no debe deducirlo de un contenido genérico con los campos que había disponibles.
Para un distribuidor hipotético, un pedido aprobado puede activar preparación de entrega y, por separado, un aviso al cliente. Registra qué sistema controla el estado de referencia y qué puede cambiar cada consumidor. Limita el mensaje a la información necesaria para esa responsabilidad.
Incluye identidad estable, correlación y estrategia de versiones adecuada. Evita datos personales o confidenciales innecesarios cuando basten una referencia y una consulta autorizada. Documenta la respuesta ante información ausente o una versión no procesable.
Distingue aceptación del intermediario y finalización del negocio
La confirmación de mensajes de Service Bus describe cómo emisores, receptores e intermediario reconocen transferencias y resultados. La documentación explica modos de recepción, bloqueos y operaciones de confirmación. Relaciona esos estados con el proceso, sin presentarlos como significados intercambiables de éxito. Transferencias, bloqueos y confirmación.
Si el intermediario acepta preparar un pedido, la aplicación puede decir que la preparación está en cola. No debe afirmar que el almacén terminó. Define cómo se registra la finalización y cómo la descubre el proceso de origen cuando importa al usuario.
Expón lo pendiente en una vista operativa con antigüedad, estado y responsable. Atención al cliente debe distinguir demora normal de fallo que necesita intervención. Los recuentos técnicos de mensajes rara vez aportan contexto suficiente.
Haz segura la entrega repetida para la operación
Un consumidor puede aplicar un cambio y fallar antes de que su confirmación llegue al intermediario. Diseña para recibirlo de nuevo. Utiliza identidad duradera de operación y transacciones adecuadas para no crear silenciosamente otro envío o compromiso de notificación.
Define qué cuenta como la misma operación. Reutilizar un identificador para trabajo diferente puede ocultar una actualización legítima; generar uno nuevo por reintento puede anular la protección contra duplicados. Conecta la identidad con la intención del negocio, además del intento de proceso.
Prueba el fallo entre aplicar el efecto y terminar de tratar el mensaje. Revela más que fallar antes de cambiar nada. Verifica que repetir produce el estado final previsto y un rastro diagnóstico comprensible.
Planifica juntas la publicación y las escrituras
Considera el límite entre registrar un pedido y publicar su mensaje. Si uno funciona y otro falla, hace falta recuperación. Escribir en SQL Server y enviar a un intermediario no son automáticamente una transacción atómica porque ocurran en el mismo método.
Evalúa un outbox transaccional: registra cambio de negocio y evento pendiente en la misma transacción local y publícalo después por otro proceso. Siguen haciendo falta duplicados, supervisión y limpieza. Trátalo como un mecanismo deliberado de consistencia, no como una etiqueta decorativa.
Para el distribuidor, concilia pedidos aprobados con solicitudes de preparación para detectar publicaciones ausentes. Un mecanismo bien diseñado reduce huecos; la conciliación demuestra la integridad real del negocio ante imprevistos.
Asigna una vía de resolución a los mensajes fallidos
Algunos fallos son temporales; otros indican solicitudes inválidas, contratos incompatibles o decisiones ausentes. Clasifícalos para evitar repetir trabajo incapaz de funcionar. Reintentar continuamente un mensaje inválido consume recursos y retrasa la atención a la causa.
Las colas de mensajes no procesables de Service Bus retienen mensajes que no pueden entregarse o procesarse bajo determinadas condiciones. Microsoft documenta su inspección y gestión. Retener solo ayuda si un equipo asume la investigación y resolución controlada. Colas de mensajes no procesables de Service Bus.
Crea una revisión con motivo, corrección propuesta y efecto esperado de repetir. Antes de reenviar, comprueba si hubo efectos parciales. Evita repetir masivamente como respuesta predeterminada a una acumulación sin explicación, especialmente si crea obligaciones externas.
Opera según los plazos del negocio
Establece cuánto puede esperar el trabajo importante. Supervisa antigüedad y resultados junto a profundidad de cola y conecta avisos con responsables. Pocos pedidos antiguos de gran valor pueden importar más que una ráfaga grande de tareas rutinarias resueltas rápido.
Ensaya caídas de consumidores, mensajes inválidos y picos. Decide si una entidad concreta necesita orden y utiliza la capacidad del servicio y reglas adecuadas. No asumas que trabajos independientes terminarán según el orden de envío.
Worktechlabs diseña integraciones asíncronas con estados claros y procesamiento recuperable. Combina el intermediario con responsabilidad sobre tareas en segundo plano y disciplina de contratos API para explicar el sistema cuando sus componentes trabajan a velocidades distintas.
Fuentes oficiales y lecturas adicionales
- Microsoft: confirmación de mensajes en Service Bus — reconocimientos y recepción.
- Microsoft: colas de mensajes no procesables — inspección y resolución de fallos retenidos.
