Este fue, sin exagerar, uno de los proyectos que más cariño le tengo de toda mi carrera. Se trataba de actualizar el sistema de fidelización de clientes de Cinesa, y cuando digo «actualizar» me quedo corto: partíamos de una base de datos bastante primitiva, con los datos de los clientes inscritos viniendo en gran parte de ficheros de texto plano —contraseñas incluidas, sin cifrar de ninguna manera—, y con las taquillas comunicándose con la central mediante líneas telefónicas punto a punto. Esto era una época en la que Internet, tal como lo entendemos ahora, ni siquiera formaba parte de la operativa habitual de este tipo de sistemas.
Me tocó de todo, la verdad. Empecé migrando toda la base de datos a SQL Server, lo cual implicaba rediseñar el modelo de datos y optimizar consultas y procedimientos almacenados que venían arrastrando limitaciones de origen. Establecimos también un mecanismo de copia de seguridad —en cintas, sí, como suena— porque era lo que había en aquel momento para garantizar que, pasara lo que pasara, la información de los clientes estuviera a salvo. Cambiamos los procesos de alta y la gestión de credenciales, con la seguridad como prioridad evidente después de ver cómo estaba montado el sistema anterior.
Pero la parte que de verdad me hizo sudar fue el rendimiento. Hablamos de una base de datos con millones de registros, sobre la que había que calcular el saldo de puntos de cada cliente en tiempo real, con un límite de menos de dos segundos de respuesta —algo que, para un cliente individual, era razonablemente factible una vez optimizado. El problema llegó con el «saldo familiar»: alguien tuvo la idea de que varias cuentas relacionadas pudieran consultar su saldo conjunto como unidad familiar, y de repente una consulta que ya estaba optimizada pasaba de milisegundos a unos diez segundos, porque ahora había que agregar varias cuentas en tiempo real en lugar de leer un único registro. Tuvimos que hilar muy fino —rediseño de índices, reestructuración del modelo, ajustar cada consulta al detalle— hasta conseguir que ese cálculo agregado respondiera con la misma rapidez que uno individual, algo que en las taquillas, con gente esperando en cola, no era negociable.
Al margen de la base de datos, también metí mano en el backend y en distintas herramientas de administración, y desarrollé un componente en C++ que permitía imprimir directamente desde el navegador en las impresoras de las taquillas —algo que hoy parece trivial, pero que entonces chocaba de frente con las limitaciones de los navegadores y sistemas operativos de la época. Ese componente nos permitió integrar la venta de entradas con el hardware ya instalado en los cines sin tener que cambiar nada de la infraestructura física.
Con el tiempo, y a medida que Internet se fue consolidando de verdad, migramos todo el sistema hacia una API desarrollada en .NET que centralizaba toda la lógica de negocio, de modo que la misma información sirviera tanto para la web oficial como para las taquillas y, más adelante, para las aplicaciones móviles. Fue un cambio de arquitectura importante, pero mereció la pena: dejamos de tener la lógica duplicada en tres sitios distintos y ganamos muchísimo en mantenibilidad.
Es un proyecto del que guardo un recuerdo especial porque tocamos absolutamente todas las capas de un sistema crítico de verdad: infraestructura, base de datos, backend, integración con hardware, y diseño de servicios. Y también porque fue un sistema que fue evolucionando durante años sin perder nunca continuidad de servicio, acompañando los cambios tecnológicos del sector según iban llegando. Al final, la cadena fue vendida a un grupo extranjero que trajo su propio departamento de desarrollo y fue sustituyendo poco a poco lo que habíamos construido — un cierre un poco agridulce para un proyecto que, mientras duró, nos encantaba.