Principia #2: Back Pressure
O cuando la ingeniería se convierte en fontanería
Si hay algo que me quitó el sueño en los últimos años fue la inestabilidad de una base de datos. Digo una, aunque en realidad fueran múltiples shards de una misma base de datos —entendiendo por shard la división balanceada por grupos de clientes (por ejemplo, 10.000 clientes por DB).
Debido al mal diseño en muchos aspectos —en los que no me atrevo a entrar por no herir sensibilidades—, era rara la semana en la que no teníamos uno o dos incidentes serios. Algunos tan graves que convertían los terminales punto de venta de los clientes en ladrillos incapaces de operar.
Como el sistema debía funcionar 24x7 y apenas teníamos ventanas de mantenimiento, los cambios para salir del atolladero había que introducirlos poco a poco. Siempre repetíamos la frase:
“Tenemos que arreglar el motor en llamas de un avión en pleno vuelo.”
Pero hoy no quiero hablar de bases de datos, sino de un fenómeno que aparece cuando cualquier sistema se satura: el back pressure —que podríamos traducir como contrapresión, aunque el término inglés es el más usado.
¿Qué es el back pressure?
En ingeniería, el back pressure se define como la resistencia que impide el flujo natural de un fluido debido a una obstrucción o estrechamiento. En software, el concepto es análogo: es la resistencia que encuentra un sistema al intentar convertir una entrada en una salida. En resumen, es lo que ocurre cuando el caudal de entrada es mucho más grande que el de salida. Por ejemplo, una petición HTTP cuya respuesta se ralentiza porque la base de datos está procesando demasiadas operaciones simultáneas. La latencia sube, las operaciones se acumulan y pronto aparecen los timeouts.
Seguro que muchos lo habéis vivido. CPU por las nubes, contención en acceso al disco, colas interminables de peticiones por procesar… Lo vemos en portales de venta de entradas cuando salen las de un concierto importante, en tiendas durante el Black Friday, o en inscripciones a carreras que se agotan en minutos.
En esos momentos, lo ideal sería que los usuarios dejaran de hacer peticiones. Pero claro, ellos no saben que hay un cuello de botella y solo están contribuyendo a que vaya a peor. Ellos solo quieren su producto, su entrada o su dorsal. Así que las peticiones se acumulan, la base de datos no da abasto y el resto de sistemas empiezan a sufrir en cadena.
La raíz del problema
Podríamos pensar que el sistema debería escalar automáticamente, aumentar capacidad, limitar conexiones, etc. Y sí, en teoría así debería ser. Pero la causa del back pressure rara vez es solo de recursos, sino que viene dado por el diseño del sistema en cuestión.
Esquemas de datos demasiado complejos, deadlocks habituales en procesos transaccionales, queries sin índices que requieren un full scan… Todo eso puede parecer bajo control en condiciones normales, pero basta un pico de tráfico para que el sistema salga ardiendo. Y cuando el fuego empieza, la solución más rápida suele ser “meter más hierro”: más CPU, más RAM, más réplicas. Pero eso solo (y con suerte) alivia el síntoma, no la causa. Lo que hay que hacer es reducir el caudal, la carga transaccional. Es decir, aliviar la presión que viene de aguas arriba.
Estrategias para aliviar la presión
No podemos pedirle a los usuarios que “hagan menos peticiones”, pero sí podemos diseñar sistemas que se defiendan mejor. Os dejo algunos de los patrones (válvulas de alivio) que más efectivas me han resultado.
Modo offline
Desarrollar las aplicaciones para que puedan funcionar sin conexión, como los terminales de punto de venta, que deberían operar con datos locales y sincronizarse periódicamente con el servidor. Se trata de diseñara la aplicación para offline-first.
Ditto: base de datos offline, en el borde (edge).
Sala de espera
Cuando se abre la venta de entradas, los usuarios entran en una cola virtual con turno y tiempo estimado para acceder a la compra. Este patrón es común y fácil de implementar.
Corto circuito (circuit breaker)
Si la latencia sube o los errores aumentan, se puede “cortocircuitar” antes de que el sistema colapse, devolviendo un error controlado y pidiendo al usuario que lo intente más tarde.
API Asíncrona
No todo debe procesarse en tiempo real. Operaciones como transformaciones, procesamientos de pagos o webhooks pueden encolarse y ejecutarse más tarde, desacoplando el tráfico entrante del procesamiento real.
Exponential back-off en cliente
Cuando una petición falla, se reintenta tras una espera creciente en el tiempo: 1s, 2s, 4s, 8s… Este simple patrón ayuda a estabilizar tanto el cliente como el servidor cuando está renqueante.
Estas estrategias no eliminan el problema de raíz, pero permiten ganar tiempo, aislar el daño y mantener la experiencia del usuario. Implementar una o varias de ellas es, en cierto modo, dotar al sistema de resiliencia operativa (sobre esto hablé en el Principia #1).
El back pressure no es solo un fenómeno técnico, sino también humano. Cuando la presión aumenta, no se trata solo de habilitar más caudal, sino de crear mecanismos que nos permitan aliviar la presión antes de que se rompan cosas. Hay veces que el remedio tiene que ser creativo, y que se ajuste a nuestras necesidades. Por ejemplo, Netflix implementó un mecanismo para limitar la concurrencia de cada servicio según su rendimiento actual (ver Netflix Tech Blog — Performance Under Load), porque no siempre 100 peticiones concurrentes es adecuado, habrá situaciones en las que haya que bajar a 50 para proteger el servicio.
Añadir más hierro al problema no siempre es la solución, porque el precio a pagar se pueden traducir en pérdidas en lugar de ganancias durante las campañas, o eventos especiales.
¿Y tú? ¿Te has encontrado con situaciones donde el sistema necesitaba de una válvula para liberar presión? Te leo en los comentarios.
¡Muchas gracias por leerme!