Reintentos, idempotencia y concurrencia acotada; refactorizar y revisar en pasos chicos

Una app móvil manda a corregir un ensayo. El backend llama a Claude, guarda la devolución y descuenta un crédito, pero tarda unos veinte segundos. A los quince, el cliente asume que falló y reenvía el pedido: el alumno recibe dos devoluciones y paga dos créditos. Nada de esto es un problema del modelo. Es ingeniería de software de siempre, y el examen la pregunta con escenarios de Claude.

REST, JSON y qué se puede repetir

En una API REST, el método dice qué efecto tiene repetir un pedido. Un GET que lee se puede repetir sin cuidado. Un POST que crea algo, cobra o manda un mail no: dos POST iguales son dos efectos.

Cuando el cliente puede reenviar un POST (por timeout, por reconexión, por un usuario que toca dos veces), hay que hacerlo idempotente:

1. El cliente genera una clave de idempotencia (idempotency key) única por operación y la manda en cada intento.
2. El servidor guarda la clave con el estado de la operación.
3. Si llega otra vez la misma clave, devuelve el resultado guardado (o “en proceso”), sin volver a llamar a Claude ni a cobrar.

Con JSON, lo mismo de siempre: validá lo que entra y lo que sale contra un esquema, y no confíes en que un campo exista porque “siempre estuvo”.

Asincronía y concurrencia con límite

Analizar trescientas reseñas una por una tarda minutos. Lanzarlas todas juntas con un gather sin límite termina en una ola de 429. La respuesta está en el medio:

• Programación asíncrona (asynchronous programming) con el cliente asíncrono del SDK, para no bloquear mientras se espera cada respuesta.
• Concurrencia acotada (bounded concurrency): un límite de pedidos en vuelo, por ejemplo con un semáforo de diez, ajustado a tus límites de tasa.
• Backoff con jitter para el 429 suelto que igual aparezca (los reintentos del SDK ya lo hacen; no sumes otro bucle encima).

Y si el trabajo no tiene a nadie esperando, la opción es la Message Batches API, que se ve en la lección siguiente.

Control de versiones y revisión de código

El código que genera la IA sigue el mismo camino que cualquier otro:

• trabajo en una rama propia, nunca push directo a una rama que se despliega sola;
• pull request con las pruebas corriendo en integración continua (CI);
• revisión de código (code review) de una persona antes de llegar a main.

Que un asistente haya escrito el cambio no lo vuelve más confiable ni menos: lo que lo hace confiable son las pruebas y la revisión.

Refactorizaciones grandes, en pasos chicos

Una refactorización (refactoring) cambia la estructura sin cambiar el comportamiento. El riesgo aparece cuando un PR de sesenta archivos mezcla renombres con un cambio de lógica escondido, como un redondeo distinto. Para que se pueda revisar:

1. Antes de tocar nada, pruebas que fijen el comportamiento actual.
2. Primero, los cambios mecánicos (renombrar, mover, extraer) en PRs chicos, que no alteran resultados.
3. Después, cada cambio de comportamiento por separado, con su prueba nueva y una descripción que lo explique.

Claude Code ayuda mucho en el paso mecánico; la separación en PRs es lo que deja ver el cambio que importa.

Las trampas típicas

• Reintentar un POST con efectos sin clave de idempotencia.
• Paralelizar sin límite, o resolver los 429 con más reintentos en vez de menos concurrencia.
• Sumar un bucle de reintentos propio encima del que trae el SDK.
• Push directo de código generado a una rama que se despliega sola.
• Un PR gigante que mezcla refactorización con cambios de lógica.

En el examen

Si hay efectos duplicados por reenvíos, buscá la clave de idempotencia del lado del servidor. Si es lento en serie y falla en paralelo, buscá el cliente asíncrono con un límite de concurrencia. Si el problema llegó a producción por código sin revisar, buscá rama, pull request, CI y revisión humana. Y si un cambio de comportamiento se escondió en una refactorización, buscá la opción que separa lo mecánico de lo que cambia resultados.