Bulkhead

Resumen

El patrón Bulkhead toma su nombre de los compartimentos estancos de un barco: si el casco se rompe en una sección, solo esa sección se inunda; el barco sigue a flote. En software, el principio es el mismo: aislar recursos entre componentes o funciones para que un componente que se sobrecarga o falla no consuma todos los recursos disponibles y tumbe el sistema entero.

La implementación más común es separar thread pools o connection pools por tipo de operación. Si una API tiene endpoints de búsqueda y endpoints de pago, asignás pools separados. Si las búsquedas se saturan por un pico de tráfico, los pagos siguen funcionando con su propio pool.

Alcance y supuestos

Este paquete cubre el concepto a nivel arquitectónico: qué es, qué problema resuelve, cómo se relaciona con otros patrones del ecosistema, y en qué contexto tiene sentido aplicarlo. No cubre detalles de implementación específicos de cada tecnología ni configuraciones de proveedores cloud concretos. Asume que el lector entiende los fundamentos de sistemas distribuidos y arquitectura de software.

Modelo mental

En un restaurante, la cocina y la barra tienen estaciones separadas. Si la barra se llena de pedidos de tragos, la cocina no se detiene: tiene sus propios cocineros, sus propios insumos y su propio espacio. Si compartieran cocineros y mesadas, un sábado a la noche con muchos tragos dejaría a los comensales sin cenar. El bulkhead es tener estaciones separadas para funciones distintas.

Uso práctico

• ✅ Aislamiento de fallas: una operación lenta o fallida no consume recursos de las otras.
• ✅ Degradación controlada: si la búsqueda falla, el pago sigue funcionando —mejor que todo caiga—.
• ✅ Priorización implícita: asignás más threads a las operaciones críticas.

Implementaciones: separar thread pools en Tomcat/Netty; connection pools distintos en HikariCP; reservar memoria por tenant en sistemas multi-tenant; usar diferentes colas en sistemas de mensajería.

Ejemplo trabajado: bulkhead en una API de comercio electrónico

Una API tiene endpoints de búsqueda de productos y de checkout. Con un thread pool único de 200 threads, un pico de búsquedas por Black Friday consume todos los threads y el checkout deja de responder —clientes no pueden comprar—. El equipo aplica bulkhead: asigna 150 threads al pool de búsqueda y 50 threads exclusivos al pool de checkout. El Black Friday siguiente, las búsquedas se saturan igual, pero el checkout sigue funcionando con sus 50 threads dedicados. Las ventas no se interrumpen.

Evidencia

• Microsoft Azure Architecture Center documenta el patrón Bulkhead como parte del catálogo de patrones de resiliencia para sistemas distribuidos.