slotline
Una plataforma de reserva de recursos (salas, pistas, equipos) sobre Spring Boot. El núcleo garantiza que un hueco nunca se reserve dos veces - incluso con alta concurrencia.
Una plataforma de reserva de recursos (salas, pistas, equipo) sobre Spring Boot. Parece trivial hasta que dos personas hacen clic en el mismo hueco en el mismo milisegundo. El núcleo garantiza que un hueco nunca se reserve dos veces, incluso con alta concurrencia.
Introducción
Reservar un hueco parece la inserción de una fila, y muchos desarrolladores lo escriben exactamente así. El problema es que la verdadera dificultad no reside en el caso típico sino en el único milisegundo en que dos personas alcanzan el mismo hueco libre. slotline está construido en torno a ese único milisegundo, no en torno al formulario de reserva.
Todo lo demás de la plataforma, los recursos, el calendario y las vistas, envuelve una sola garantía: que un hueco tenga exactamente un ganador. Eso es lo que decide si el sistema es serio o solo parece funcionar hasta la primera multitud.
Toda la dificultad cabe en un milisegundo
Una implementación ingenua hace dos pasos: comprueba si el hueco está libre y luego lo escribe. Entre esos pasos hay una grieta en la que un segundo usuario logra ver el mismo hueco como libre. Ambos pasan la comprobación, ambos escriben, y tienes dos reservas para un hueco que nadie sabía que fueran posibles.
slotline lo trata como el problema principal a resolver, no como un caso límite. El modelo del dominio es claro precisamente para que esta única garantía resulte evidente al leer el código, y no quede enterrada en algún lugar de una capa de servicio.
Comprobar la disponibilidad y escribir la reserva no son dos operaciones separadas. Si lo son, tienes una condición de carrera. La garantía viene de la base de datos, mediante una restricción única sobre recurso más franja horaria, no de una comprobación en el código de la aplicación.
La restricción única traslada la decisión al único lugar donde la concurrencia se serializa de verdad: el motor de la base de datos. No importa cuántos usuarios hagan clic a la vez, porque al ganador lo decide una escritura atómica, y los perdedores reciben un error de conflicto limpio en lugar de una doble reserva silenciosa.
Una prueba que puede fallar de verdad
Es fácil escribir una prueba que reserva una vez y comprueba que funcionó. Eso no prueba nada, porque nunca toca la condición que debe sostenerse. La prueba valiosa lanza muchos hilos sobre el mismo hueco a la vez y comprueba que exactamente uno gana mientras el resto recibe un error de conflicto limpio.
Asalto simultáneo a un hueco (orientativo)
La comprobación es contrafactual: quita la restricción única y la misma prueba empieza a dejar pasar dos reservas. Si la prueba sigue en verde después de quitar la salvaguarda, no estaba vigilando nada.
Un ganador, siempre
El resultado es una plataforma que bajo carga se comporta exactamente igual que con un solo usuario: un hueco tiene un propietario, y punto. No hay un estado en el que dos personas se marchen con el mismo hueco, porque esa posibilidad se cortó de raíz, en la base de datos, no se parcheó en la interfaz.
Más proyectos
Más trabajos de la misma categoría - mira cómo abordamos retos parecidos.
¿Tiene un proyecto similar?
Escríbenos - el presupuesto es gratuito y llega en una hora.