Inbox transaccional
Un inbox transaccional usa registros duraderos de mensajes para proteger el procesamiento local frente a entregas duplicadas.
Un inbox transaccional usa registros duraderos de mensajes para proteger el procesamiento local frente a entregas duplicadas. En la variante descrita aquí, la marca de mensaje procesado y su cambio en los datos de negocio se guardan en la misma transacción de base de datos.
Un servicio ficticio cuyo nombre de consumidor es report-worker recibe el mensaje E-42. Inserta en su inbox la combinación del consumidor y el identificador del mensaje y aumenta un contador de informes de 6 a 7. Ambos cambios se confirman juntos. Una restricción de unicidad en la base de datos para esa combinación también protege frente a instancias que trabajan simultáneamente. Consultar primero y escribir después no basta por sí solo.
Importa el momento del fallo
Si la transacción falla antes del commit, no persisten ni la entrada del inbox ni el cambio del contador. Si el commit se completa pero se pierde la posterior confirmación al broker, E-42 puede llegar de nuevo. La entrada existente evita entonces otro incremento hasta 8. La confirmación al broker no forma parte de esta transacción local.
La idempotencia describe el efecto seguro de una repetición; el inbox es un posible patrón para conseguirlo. Un outbox guarda los mensajes salientes junto con el cambio local. El inbox por sí solo no garantiza que una llamada HTTP externa se ejecute o un correo se envíe exactamente una vez. La conservación de los identificadores debe cubrir el periodo posible de nuevas entregas y reprocesamientos; las entradas eliminadas demasiado pronto dejan de proteger frente a duplicados posteriores.
Fuentes
Términos relacionados
- IdempotenciaUna operación idempotente produce el mismo efecto previsto sobre el estado al repetirse idénticamente que al ejecutarse una vez.
- Confirmación de mensajesLa confirmación informa al broker de que una entrega se ha recibido o procesado según la regla acordada.
- Variación aleatoria entre reintentosEl jitter de reintentos varía aleatoriamente las esperas para repartir los reintentos y reducir las solicitudes simultáneas de varios clientes.
- Espacio de cliente de pruebasUn espacio lógico delimitado de una aplicación multitenant, configurado para comprobaciones.
- Reenvío de webhookEl reenvío de webhook vuelve a transmitir una notificación. La recuperación deliberada y los ataques de repetición requieren comprobaciones diferentes.
- Clave de idempotenciaUna clave de idempotencia identifica repeticiones de una misma solicitud. Su efecto depende del ámbito, la conservación y las reglas de la API.
Artículos sobre el tema
APIs e integración con ASES
ERP, CRM y tienda bien conectados