Sitio Web Corporativo: BALTIC PALACE

#Baltic-palace.com, tecnología para un lugar singular junto al Báltico

El tráfico de un alojamiento en la costa báltica no es una línea, es una sucesión de picos estrechos. Enero, cuando la gente planifica el verano. El puente largo de mayo. Y después julio y agosto. Entre esos momentos el sitio atiende unas decenas de visitas al día. Esa forma del tráfico, y no una preferencia técnica, explica casi todas las decisiones de arquitectura de este proyecto: una infraestructura dimensionada para el pico quema dinero la mayor parte del año, y una dimensionada para la media se cae exactamente en la semana en la que el negocio gana.

Baltic Palace está en Pobierowo, en el cordón dunar de Pomerania Occidental, a unos cien metros del acceso a la playa, y fue proyectado por el estudio MTA Architekci. Cuenta con cuarenta y cuatro habitaciones y apartamentos, un tamaño que lo sitúa lejos tanto de la pensión familiar como de la cadena hotelera. En la planta baja están el vestíbulo, el bar, el restaurante, las salas de tratamiento y una zona de SPA con dos piscinas y saunas, y el establecimiento dispone además de espacio para reuniones.

El proyecto se ejecutó en 2017 y llevó alrededor de seis semanas. El cliente entregó la maquetación y la disposición de los elementos, de modo que mi parte fue traducir eso a plantillas, a un modelo de contenido y a un comportamiento responsivo, no decidir la estética.

#Objetivo de baltic-palace.com y su audiencia

El encargo no era generar demanda desde cero. El tráfico de marca ya existía y el sitio tenía que dejar de perderlo. Un alojamiento de este tamaño no compite en alcance con los portales de reserva, compite en margen: cada reserva que pasa por un intermediario deja allí su comisión, así que el sitio propio tiene una tarea medible en dinero, convencer a quien ya conoce el nombre de terminar la reserva en el origen.

En la práctica eso significa que el camino de reserva debe soportar lo que la gente hace de verdad, no lo que hace una demostración. Abren dos pestañas y comparan fechas. Pulsan atrás a mitad del formulario. Empiezan en el móvil, en un tren con cobertura intermitente, y terminan en el portátil tres días después. Un flujo de reserva que solo funciona cuando no ocurre nada raro es un flujo que funciona en la demostración.

Hay además un segundo público que lee las mismas páginas con otros ojos. Quien organiza una reunión o un grupo busca restricciones, no ambiente: aforo según la disposición de sillas, si el catering puede darse en el restaurante, a qué distancia está la estación más cercana. Ese lector decide sobre una especificación, y una especificación enterrada en un párrafo de prosa es una especificación que nadie encuentra. Por eso esos valores viven en campos estructurados y no en texto corrido.

Conviene decir también qué no hay en esta página. No hay indicadores de resultado: ni porcentaje de aumento de reservas, ni ocupación, ni puntuación sobre cinco. Los datos comerciales del establecimiento pertenecen al establecimiento y no al caso de estudio de su proveedor, y ninguna de esas cifras podría respaldarse aquí con una fuente. Lo que sí puede contarse con honestidad, y lo único que se traslada al siguiente proyecto, son las decisiones técnicas y sus motivos.

#Funcionalidades técnicas de baltic-palace.com

La capa de interfaz se apoya en Tailwind CSS y media queries, con WCAG 2.1 en el horizonte. La accesibilidad aquí no es un trámite. Una parte importante de los huéspedes tiene cierta edad, y un formulario de reserva leído en el móvil a pleno sol necesita un contraste que el gris claro elegante sobre blanco sencillamente no da. Por la misma razón los campos llevan etiquetas visibles en lugar de textos de ejemplo que desaparecen con la primera tecla.

Las galerías y la presentación del volumen del edificio son la parte más pesada del sitio. La fotografía de arquitectura e interiores es contenido de primer orden, no adorno, y comprimirla hasta que la textura del revoco se convierte en una mancha elimina el principal argumento del alojamiento. El volumen se muestra como modelo tridimensional en Three.js, y las galerías se cargan de forma dinámica mediante GraphQL con tratamiento de srcset.

GraphQL tiene aquí un motivo concreto. Un extremo convencional devuelve todos los campos de cada imagen, incluidos los que una vista de lista nunca usa, y una sola petición por una docena de objetos con metadatos completos puede pesar más que las propias miniaturas. Una consulta que declara que necesita tres campos traslada ese coste de la red a la base de datos, donde es más barato.

Las reservas pasan por un módulo dedicado con integración de Stripe, validación en el servidor y almacenamiento en PostgreSQL con cifrado AES-256. La validación en servidor no sobra al lado de la del navegador. El formulario acepta un intervalo de fechas, y un intervalo de fechas es el campo más fácil de romper en cualquier sistema de reservas: el botón atrás, dos pestañas abiertas, una fecha libre al cargar la página y ocupada al enviar el formulario. Desde el lado del cliente los tres casos parecen un formulario perfectamente válido.

La sección informativa sobre Pobierowo y el alojamiento está escrita para las búsquedas que realmente se hacen en esa zona, con aviso acelerado de cambios a través de la Google Indexing API. Las copias de seguridad van automáticamente a Amazon S3 con replicación entre regiones, versionado y compresión Zstandard. El versionado pesa más que la copia en sí, porque el fallo que de verdad le ocurre a un alojamiento no es un servidor caído, sino una lista de precios sobrescrita con el archivo equivocado dos días antes de un puente.

El rendimiento descansa en Varnish para la caché de servidor y en Cloudflare para la optimización multimedia, con WebP y preconnect para los recursos clave sobre HTTP/3. La ubicación la resuelve un módulo con Mapbox GL JS, datos GeoJSON y teselado. En un alojamiento costero el mapa responde a una pregunta que nadie formula en voz alta: cuánto hay realmente hasta el mar, cuando todos los establecimientos en un kilómetro a la redonda dicen de sí mismos que están junto a la playa.

#Desafíos técnicos y cómo se resolvieron

El peso de la galería apareció en las primeras pruebas. Un número alto de imágenes en resolución elevada retrasaba la primera pintura. Redis se encarga de la caché de consultas y Fastly actúa como segunda capa de CDN para servir los medios en paralelo. Separar los medios tiene sentido porque la galería y el documento HTML tienen perfiles de invalidación distintos: el texto de la oferta cambia cada pocas semanas, las fotos de una sesión prácticamente nunca. Mantener ambos bajo la misma política obliga a recargar imágenes de más o a refrescar el texto de menos.

El modelo tridimensional frenaba los navegadores móviles, lo que en un establecimiento con público mayoritariamente móvil era un problema real y no teórico. La reducción de polígonos y la compresión de texturas con Draco resolvieron la parte de transferencia. El compromiso merece decirse sin rodeos: cada reducción de ese tipo quita detalle, y el detalle es la única razón por la que el modelo existe. La línea está donde el volumen sigue leyéndose como este volumen concreto y no como un bloque cualquiera.

El sistema de reservas se atascaba en los picos. La causa es estructural. Una reserva tiene que comprobar disponibilidad, bloquear las fechas, cobrar y enviar la confirmación, y la persona espera al último paso aunque solo le importe el primero. Separarlos con RabbitMQ hace que el bloqueo y la respuesta ocurran de inmediato, mientras la confirmación y la sincronización posterior pasan a una cola. El rate limiting a nivel de Nginx protege ese mismo extremo del doble clic y de los bots que rastrean disponibilidad durante toda la temporada.

La caché desactualizada fue el último de estos problemas y el más caro en términos comerciales. Un cambio en la oferta que nadie ve es una llamada de un huésped molesto. Varnish con purga disparada por webhook, más Edge Side Includes para las secciones dinámicas, lo resuelve sin renunciar a la caché en el resto. ESI responde a una tensión concreta: una página de habitación es en un noventa por ciento contenido que no cambia en meses y en un porcentaje pequeño precio y disponibilidad que cambian a diario. Sin separar esas capas, la vida de la caché del documento entero tendría que fijarse según su fragmento más efímero, que equivale a apagarla.

#Tecnologías utilizadas

Yoast SEO gestiona metadatos, mapas XML y avisos a los buscadores. UpdraftPlus ejecuta las copias a Amazon S3 con replicación entre regiones y cifrado AES-256. Cloudflare aporta la capa de CDN con Argo Smart Routing, compresión Brotli y protección frente a tráfico volumétrico. Redis mantiene la caché de objetos con sharding y persistencia para consultas y sesiones. Varnish opera la caché de páginas sobre VCL propio, con modo grace y soporte de ESI.

El modo grace merece una frase aparte, porque es el ajuste más infravalorado de esta configuración. Permite servir una página ligeramente caducada cuando el backend no responde, en lugar de mostrar un error. En temporada alta, la diferencia entre una página de hace dos minutos y un mensaje de error es la diferencia entre una reserva y ninguna.

Lighthouse corre automáticamente en el proceso de CI/CD sobre GitHub Actions, de modo que una regresión de rendimiento sale en el cambio y no en una queja. RabbitMQ encola el trabajo de reservas y los correos de confirmación con reintentos. Fastly añade una segunda vía de distribución multimedia con optimización geográfica. Mapbox GL JS dibuja el mapa con teselado. GraphQL resuelve la carga de datos de galería e información con agrupación de consultas, y Git junto con el proceso mantiene el historial en un estado donde se puede revertir una cosa y no una semana entera.

Conviene señalar lo que esta lista no dice. No dice cómo se comporta el mismo conjunto en otro alojamiento. Tres capas de caché para cuarenta y cuatro habitaciones con una estacionalidad marcada se justifican por esta forma de tráfico y por ninguna otra. En un establecimiento con demanda estable todo el año, la misma configuración sería un lastre cuyo mantenimiento supera el beneficio.

#Gestión y soporte técnico

El sitio requiere seguimiento continuo. Las actualizaciones de sistema y extensiones pasan por un entorno de pruebas con copia completa, no por producción con optimismo. La diferencia se ve mejor que en ningún sitio en el módulo de reservas: una actualización probada sobre una instalación vacía siempre pasa, porque no hay nada que romper, mientras que la misma actualización contra una copia de producción revela de inmediato que la extensión ha cambiado el formato de fecha en los registros existentes.

Cloudflare, Redis y Fastly sostienen el rendimiento bajo carga; Varnish y RabbitMQ sostienen la estabilidad de los procesos dinámicos. Las consultas SQL pasan por índices compuestos, porque una búsqueda de disponibilidad filtra siempre por fecha y tipo de habitación a la vez, y un índice sobre cualquiera de esas columnas por separado no sirve para esa consulta. La caché se purga de forma quirúrgica en las actualizaciones de contenido y no en bloque, porque una purga completa antes de un puente significa que los primeros cientos de visitas caen sobre una caché fría.

La zona de SPA y las salas de reunión se comportan además de otra manera dentro del modelo de contenido. Una habitación tiene disponibilidad y precio, así que es un registro. El SPA no tiene disponibilidad en ese sentido, tiene tratamientos, horarios y restricciones de temporada. Una sala tiene un aforo que cambia con la disposición del mobiliario, y es ese número, y no la fotografía, el que provoca la consulta. Forzar los tres en un único tipo de contenido produce campos vacíos dos de cada tres veces y un panel editorial en el que nadie se orienta un año después.

El sitio puede crecer hacia una integración con el sistema hotelero de recepción, un módulo de promociones de temporada o una sección de opiniones de huéspedes. Cada una de esas direcciones es un alcance propio, presupuestado tras el análisis y no añadido por el camino.