Los compartimentos estancos por dependencia mantienen disponibles los endpoints no relacionados cuando una dependencia se atasca

Hipótesis

El patrón bulkhead (compartimento estanco, citado) aísla los elementos de una aplicación en grupos, de modo que si uno falla, los demás siguen funcionando; Resilience4j (citado) lo implementa como un semáforo que limita las ejecuciones concurrentes o como un grupo fijo de hilos con una cola acotada. La hipótesis es que el beneficio del patrón es mayor para el caso de una dependencia lenta que para el de una dependencia caída: una dependencia que responde justo dentro del tiempo de espera del cliente ocupa un espacio durante todo ese tiempo, y en un grupo compartido esto priva de recursos a endpoints que nunca la llaman. Con un grupo acotado por dependencia, las llamadas a la dependencia lenta se rechazan rápidamente en cuanto su grupo se llena, y los demás endpoints mantienen una latencia y una tasa de error cercanas a las habituales.

Predicción

En un servicio con los endpoints /a (llama a la dependencia A) y /b (llama a la dependencia B) que comparten un grupo de tamaño P, inyectar en A un retraso justo por debajo del tiempo de espera del cliente elevará, bajo una tasa de solicitudes constante en bucle abierto, la latencia p99 y la tasa de error de /b hasta el nivel de /a en pocos periodos de tiempo de espera. Con dos compartimentos de tamaño P/2, /b se mantendrá dentro de su nivel habitual, mientras que /a mostrará rechazos rápidos en lugar de agotamientos de tiempo de espera. El rendimiento total de solicitudes exitosas de /a en condiciones normales será menor con el grupo dividido, lo cual es el costo del aislamiento.

Prueba propuesta

1. Construir el servicio de dos endpoints con un grupo compartido configurable o con compartimentos estancos de semáforo por dependencia; mantener los tiempos de espera idénticos en ambas configuraciones.
2. Colocar un proxy de inyección de fallos delante de la dependencia A y añadir una latencia equivalente a aproximadamente el 90 % del tiempo de espera del cliente.
3. Generar tráfico hacia ambos endpoints a una tasa de llegada fija (modelo abierto) durante un periodo varias veces mayor que el tiempo de espera, una vez por configuración.
4. Registrar la latencia p50 y p99, el tipo de error (tiempo de espera agotado, rechazo) y la tasa de éxito por endpoint a lo largo del tiempo.
5. Repetir el experimento con A devolviendo errores de inmediato en lugar de atascarse, para poner a prueba la afirmación de que la diferencia entre configuraciones es menor en ese caso.

Estado

No se afirma ningún resultado. El efecto depende de que el grupo sea realmente el recurso escaso; un servicio totalmente asíncrono puede mostrar la misma privación de recursos a través de límites de conexión o de la saturación del bucle de eventos, y la prueba debería registrar qué recurso se agotó.