Cómo MyLock Lite mantiene las taquillas inteligentes abriéndose cuando se cae internet

La mayoría de las taquillas inteligentes tienen el mismo modo de fallo. El Wi-Fi se cae diez minutos, el respaldo móvil no está configurado, un router de arriba se reinicia — y de repente el cliente que está delante de una taquilla no puede abrir la puerta. El hardware funciona. La cerradura funciona. Lo que se ha roto es el viaje de ida y vuelta a un servidor a tres husos horarios de distancia que tenía que dar el visto bueno a la orden de "abrir".

Hemos visto ese modo de fallo en suficientes gimnasios y coworkings como para construir toda una gama de producto pensada para no repetirlo. MyLock Lite es la rama offline-first de la plataforma MyLock: panel en la nube para tu equipo, inteligencia autocontenida en cada local, sin llamada de servidor en el camino crítico.

Qué significa realmente "offline-first" en el diseño

La pregunta arquitectónica importante sobre cualquier sistema de taquillas inteligentes es: ¿dónde se toma la decisión autoritativa de "sí, abre esta puerta"? En un sistema puramente en la nube esa decisión se toma en un servidor — el terminal de la taquilla toma el código escaneado, lo envía a la nube, espera una respuesta firmada y entonces dispara la cerradura. Cada apertura es una petición síncrona. Cuando la red flaquea, la apertura flaquea.

Lite invierte el flujo. Cada local dispone de una pequeña unidad on-site — una pieza de hardware, alimentada por red, sin baterías que cambiar, que arranca directamente en modo quiosco. Contiene el conjunto actual de reglas de acceso, los códigos válidos y el registro de auditoría. Cuando un cliente escanea un código, la unidad on-site lo verifica localmente y abre la puerta al instante. El panel en la nube es donde tu equipo crea y revoca códigos, consulta el histórico y cambia modos — pero la puerta no necesita el panel para abrirse.

La conectividad, en este modelo, es una comodidad para el operador, no una dependencia para el cliente.

Seguridad cuando no hay llamada al servidor

La contra natural a la verificación offline es: "si la puerta no consulta al servidor, ¿cómo sé que un código es válido y no falsificado?" Esta es la parte del diseño que más tardó en cuajar, así que merece la pena explicarla.

Cada acción de administración — generar un código de acceso para un cliente, abrir una taquilla en remoto, revocar permisos, cambiar una batería de pública a privada — sale del panel como una carga firmada criptográficamente. La firma se produce con claves que sólo posee el panel. La unidad on-site sólo tiene la mitad pública necesaria para verificar firmas. Cuando un código llega al terminal, la unidad comprueba la firma localmente contra la clave pública, comprueba la caducidad incluida en la carga, y sólo abre la puerta si ambos pasan.

De ese diseño salen dos propiedades. Primera, un código no puede ser falsificado por alguien que no tenga la clave privada del panel — ni siquiera si puede leer el código en la pantalla del móvil del cliente. Segunda, la clave privada nunca viaja por el navegador, ni por la red, ni por la unidad on-site. Se queda en el servidor, donde debe estar.

El registro de auditoría funciona igual en sentido inverso: cada apertura, cada acción de administración, cada cambio de modo se escribe en el registro local con timestamp y firma, así que las entradas son a prueba de manipulación. Cuando hay conectividad, el registro sincroniza contra el panel para consultarlo — pero incluso sin conexión, el registro está intacto y es defendible legalmente.

Lo que ve el cliente: un escaneo, sin app

Para el usuario final, toda esa arquitectura desaparece. El cliente llega a la batería de taquillas, escanea un QR (del email de confirmación generado por el panel, de un ticket impreso, de un recibo o del perfil de socio) y la puerta asignada se abre. Sin app que instalar. Sin cuenta que crear. Sin esperar a un spinner.

Si tu negocio necesita modo de acceso público — alguien que pasa por delante, elige una taquilla libre, introduce un PIN — la misma unidad soporta ese flujo. Y si necesitas alternar una batería entre público y privado (por ejemplo, privado para socios durante el día, público para recogida de compras por la tarde), es un interruptor del panel que se aplica en la siguiente sincronización.

Lo que ve el operador: un panel, todas las ubicaciones

El panel en la nube es la capa que más nos hemos esforzado en simplificar. Si operas más de una ubicación, es donde se hace el trabajo del día.

Cada local que gestiona tu negocio aparece en el mismo panel. Puedes generar códigos de acceso para un local concreto (o para una taquilla concreta dentro de un local), ver la ocupación actual, revisar el histórico completo de quién abrió qué y cuándo, revocar un código con un clic y empujar cambios de configuración a todas tus ubicaciones a la vez. El registro de auditoría es consultable — filtra por usuario, por taquilla, por ventana de tiempo — que es la postura de logging que desearíamos que más plataformas tuvieran por defecto y que el caso de Bucarest detalla para un despliegue de Cloud.

La configuración es deliberadamente ligera. No hay tickets de ingeniería que abrir cuando quieres cambiar cómo funcionan las caducidades o qué batería de taquillas es pública. El panel lo cubre.

Dónde encaja Lite

El modelo offline-first encaja de forma natural siempre que el coste operacional de un corte de conectividad de cinco minutos sea desproporcionado respecto al valor de las comprobaciones en servidor. Eso cubre la mayor parte del mercado en despliegues pequeños o de pocos locales:

• Gimnasios — los socios esperan abrir su taquilla al instante, en medio del entrenamiento, sin paciencia para un spinner de "conectando…".
• Coworkings — quieres que los socios guarden sus cosas sin que tú seas el garante del SLA de la red.
• Spas y centros de bienestar — el cliente está en albornoz. No va a reabrir una app.
• Universidades — el tráfico de estudiantes se dispara en el cambio de clase, exactamente cuando la red del campus está saturada. El acceso a taquillas no puede sumarse a esa cola.
• Clínicas y centros sanitarios — el flujo de pacientes no puede esperar a un router.
• Retail con recogida click-and-collect — el comprador viene a recoger un pedido. Si la recogida tarda más que el checkout que la generó, pierdes al cliente.

Si cualquiera de los anteriores suena a tu operación, Lite es probablemente la gama correcta. Si necesitas la gestión remota completa, las integraciones y el análisis en vivo de MyLock Cloud, tenemos una guía de decisión que recorre los compromisos — pero para la mayoría de despliegues de un local o de pocos locales, Lite es la respuesta honesta.

Cómo es realmente instalar Lite

El kit de instalación es deliberadamente pequeño. Una unidad on-site por local, montada en la estación de taquillas, alimentada por red. Cableado a las baterías de taquillas (mecánico, una sola vez). Unas horas de puesta en marcha on-site para enrolar la unidad con el panel, cargar el conjunto de reglas inicial y entregarla a operaciones. Ese es todo el despliegue.

No hay suscripción atada a precio por usuario, ni fee por apertura, ni coste mensual recurrente por puerta. Pagas por el hardware y por el acceso a la plataforma. A partir de ahí, el modelo operacional es: gestiona desde cualquier sitio, corre en cada local de forma autónoma, no te preocupes de si hay internet cuando aparezca un cliente.

Pruébalo

Si operas taquillas hoy y el problema de "cuando se cae el Wi-Fi, se caen nuestras taquillas" te suena familiar, contáctanos — te explicaremos el dimensionado, la unidad on-site y qué plazo realista tiene para tu configuración concreta.