¿Te has preguntado por qué una aplicación que usas con frecuencia, como aplicaciones bancarias, sitios web universitarios o compra de boletos, a menudo está caída o es lenta, pero sitios web con mucho más tráfico siempre están rápidos y listos para usar?

Esto podría suceder por diferentes razones, como que la aplicación no esté suficientemente optimizada, la arquitectura no sea adecuada y muchas más. Pero a veces, no es porque los desarrolladores no quieran hacerla más resistente los picos de trafico. Ocasionalmente, algunas aplicaciones requieren más trabajo para escalar.

¿Todas las aplicaciones cuestan lo mismo para escalarlas, verdad? No, depende de muchas cosas, pero una a considerar es el teorema CAP.

¿Qué diablos es el teorema CAP?

Primero que todo, hablemos de sistemas distribuidos. Cuando hay un sistema distribuido, generalmente queremos que este sistema tenga una excelente disponibilidad, consistencia de datos y resiliencia a la partición. Estas características son las que representa CAP en inglés: Consistency Availability Partition.

El teorema nos dice que la consistencia y la disponibilidad son complicadas cuando ocurre una partición en este tipo de sistema, así que debemos decidir cuál debemos priorizar.

¿Por qué no podemos tener las tres?

Estas características se basan en lo que hará el sistema una vez que se detecte una partición. Y tenemos dos opciones:

1. Bloquear algunas acciones para asegurar la consistencia de datos.

2. Permitir todas las acciones, pero perder la consistencia de datos.

Optar por la disponibilidad sobre la consistencia no implica un cierre completo del sistema; en su lugar, se refiere a mantener capacidades transaccionales incluso durante problemas relacionados con la partición.

Priorizar la consistencia implica bloquear transacciones para las partes afectadas mientras se asegura de que el sistema siga operativo.

Ejemplos

Considera un escenario en el que eres parte de un equipo que desarrolla una aplicación de redes sociales. En este contexto, sacrificar un 'me gusta' o potencialmente duplicar los recuentos de 'me gusta' debido a la partición puede ser considerado aceptable. Aunque no es ideal, es preferible a mantener la disponibilidad y evitar que los usuarios interactúen con la plataforma debido a problemas relacionados con la partición.

Por otro lado, en el caso de una aplicación bancaria, asegurar que solo los usuarios con fondos suficientes puedan hacer retiros es fundamental. En consecuencia, el sistema optaría por bloquear transacciones durante eventos de partición para mantener la integridad de los datos.

¿Cómo afecta esto al rendimiento de mi software?

Escalar un sistema se vuelve más desafiante cuando la consistencia de datos es una preocupación crítica. Sin embargo, ¿esto implica que sea imposible escalar dichos sistemas?

No, si ese fuera el caso, las aplicaciones bancarias no podrían soportar la cantidad de usuarios que tienen; simplemente es más difícil hacerlo.

Mitigando problemas de partición

Existen diversas estrategias que pueden mejorar la disponibilidad del sistema. Tomando el ejemplo bancario:

El sistema puede restringir los montos de retiro permitidos mientras se abordan los problemas de partición.

Este proceso generalmente se desarrolla de la siguiente manera:

• Estado óptimo

• Detección de particiones

• Entrar en modo de partición: Durante esta fase, la aplicación podría limitar las opciones de retiro para los usuarios afectados. Además, el sistema debe determinar qué transacciones priorizar, a menudo utilizando registros, vectores u otras estrategias alternativas.

• Iniciar la recuperación de la partición: Asegurar que todos los datos se almacenen con precisión e implementar procesos para rectificar los problemas de partición.

¿Por qué tenemos que hacer todo esto para tener más disponibilidad?

Porque a veces el costo de negar solicitudes y tener nuestra consistencia es más alto que priorizar la disponibilidad de nuestros sistemas. Entonces, creamos disponibilidad con algunas características adicionales para recuperarnos de la mejor manera posible.