Explica qué operaciones puede reintentar el driver, cómo se identifican escrituras retryable y qué errores o side effects siguen requiriendo lógica de aplicación.
Retryable reads y retryable writes permiten que el driver repita automáticamente determinadas operaciones ante errores transitorios de red, elecciones o cambios de primary. El objetivo es ocultar fallos breves sin obligar a la aplicación a implementar retries inseguros.
Texto
cliente envía operación
→ conexión falla o cambia el primary
→ driver clasifica el error
→ reintenta una operación compatible
No cualquier operación es retryable y el mecanismo no vuelve idempotentes los efectos externos de la aplicación.
servidor aplica la escritura
→ respuesta se pierde
→ cliente no sabe si ocurrió
Un retryable write utiliza session e identificadores internos para que el servidor reconozca ciertos reintentos de la misma operación y no aplique dos veces el write compatible.
La lista exacta de operaciones y restricciones depende de la versión del servidor y driver. Verifica documentación actual y no asumas que updateMany, un bulk completo o cualquier transacción se comportan igual.
Para retries manuales usa espera creciente y jitter. Sin ellos, cientos de instancias pueden reintentar simultáneamente después de un failover y empeorar la recuperación.
Texto
intento 1 → espera corta
intento 2 → espera mayor + jitter
intento 3 → límite y error
Define un presupuesto total. Aumentar server selection, socket y application timeout sin coordinación puede producir requests que siguen trabajando después de que el usuario abandonó.
Un timeout no debe traducirse automáticamente a “no ocurrió”. Reconciliar por ID o estado puede ser necesario.
Un bulk puede tener resultados parciales. Reintentar todo duplica operaciones no idempotentes. Conserva identidad por fila, procesa batches y consulta qué se aplicó.
Migraciones deben usar preconditions como schemaVersion y checkpoints para reanudar sin repetir cambios.
Retryable operations resuelven fallos transitorios del protocolo, no toda la idempotencia del negocio. Conoce qué repite el driver, usa claves de intención para requests, añade backoff a retries manuales y trata timeouts como resultados potencialmente ambiguos.
Comprueba lo aprendido
¿Qué problema resuelve un retryable write?
¿Por qué un timeout es ambiguo?
¿Qué diferencia existe entre retry del driver y de aplicación?