Saltar al contenido
ES · EspañolEN · EnglishIT · Italiano
Menú

Caso de estudio · Producto propio · pre-lanzamiento

EscapaYa

Marketplace de reservas de hoteles por horas, con APIs, pagos y notificaciones.

  • NestJS
  • PostgreSQL
  • Prisma
  • Redis
  • BullMQ
  • Flutter
  • Next.js
  • Cloudflare
Visitar escapaya.com ↗

El problema

Hay hoteles con habitaciones disponibles que prácticamente no existen digitalmente.

¿Cómo hacemos que encontrar y reservar unas horas sea sencillo?

Ricardo

EscapaYa reúne reservas por horas, pagos, geolocalización y notificaciones. El backend conecta estas operaciones con la app Flutter y los procesos en segundo plano.

Contexto

Un producto propio, construido de punta a punta: app, web, API, pagos y notificaciones. Está en pre-lanzamiento, así que esta página habla de decisiones, no de métricas.

Mi rol

Producto, arquitectura y código: definir el alcance, diseñar la arquitectura y construir backend, app y web.

Restricciones

  • Reintentos e idempotencia en operaciones críticas.
  • Disponibilidad por horas, más fina que una reserva por noche.
  • Pagos y notificaciones conectados mediante APIs y procesos asíncronos.
  • Mobile first: la reserva ocurre en el celular.

Arquitectura

Esquema explicativo basado en el stack del producto. Los flujos ilustran cómo se conectan APIs, datos, colas y notificaciones. Toca una pieza para entender su función.

  1. App · Flutter

    Qué resuelve
    La app de reservas para Android e iOS.
    Por qué existe
    Un solo código para las dos plataformas. Una reserva por horas se hace en el celular, muchas veces el mismo día.
    Qué otra opción había
    Dos apps nativas: el doble de trabajo para un equipo chico.

  2. Web · Next.js

    Qué resuelve
    La web pública: búsqueda, fichas de hoteles y páginas para buscadores.
    Por qué existe
    Quien busca un hotel por horas llega desde Google: las páginas tienen que existir para los buscadores.
    Qué otra opción había
    Una SPA sin render en servidor: invisible para SEO.

  3. Borde · Cloudflare

    Qué resuelve
    La puerta de entrada: caché, TLS y una primera capa contra abuso.
    Por qué existe
    Imágenes y páginas cerca del usuario, sin cargar el servidor con lo que no cambia.
    Qué otra opción había
    Servir todo desde el origen.

  4. API · NestJS

    Qué resuelve
    Un solo punto de entrada para app y web: autenticación, validación y reglas de cada request.
    Por qué existe
    Módulos claros dentro de una sola aplicación: se despliega y se opera como una pieza.
    Qué otra opción había
    Microservicios desde el día uno: demasiada operación para un producto en pre-lanzamiento.

  5. Reservas · NestJS modules

    Qué resuelve
    El dominio: hoteles, habitaciones, disponibilidad por horas y reservas.
    Por qué existe
    Acá vive la regla difícil: que dos personas no reserven la misma habitación a la misma hora.
    Qué otra opción había
    Lógica en procedimientos de la base de datos: difícil de testear y de cambiar.

  6. Base de datos · PostgreSQL · Prisma

    Qué resuelve
    La fuente de verdad: hoteles, habitaciones y reservas.
    Por qué existe
    Transacciones y restricciones para que una reserva nunca se duplique.
    Qué otra opción había
    Una base NoSQL: más flexible, sin las garantías que pide una reserva.

  7. Caché · Redis

    Qué resuelve
    Lo que se consulta seguido y cambia poco: disponibilidad reciente, sesiones.
    Por qué existe
    Responde rápido sin tocar la base de datos en cada búsqueda.
    Qué otra opción había
    Ir siempre a la base de datos.

  8. Archivos · Object storage

    Qué resuelve
    Fotos de hoteles y habitaciones.
    Por qué existe
    Los archivos grandes fuera de la base de datos, servidos por el borde.
    Qué otra opción había
    Guardarlas en el servidor: no escala y complica cada deploy.

  9. Colas · BullMQ

    Qué resuelve
    El trabajo que no cabe en el request: confirmaciones, recordatorios, vencimientos.
    Por qué existe
    Nadie espera a que salga un mensaje, y si algo falla se reintenta solo.
    Qué otra opción había
    Cron con polling, o un broker aparte. BullMQ reutiliza Redis, que ya estaba.

  10. Avisos · FCM · WhatsApp

    Qué resuelve
    Avisos al usuario y al hotel.
    Por qué existe
    Una reserva por horas es inmediata: el hotel tiene que enterarse ya.
    Qué otra opción había
    Solo email: llega tarde y nadie lo lee a tiempo.

  11. Pagos · Payment provider

    Qué resuelve
    El cobro de la reserva, con un proveedor de pagos.
    Por qué existe
    El dinero lo maneja un tercero certificado; la API solo guarda el estado del pago.
    Qué otra opción había
    Cobrar en el hotel: más fricción y más reservas que nunca llegan.

Resultados

Pre-lanzamiento. Sin métricas públicas todavía: cuando existan datos reales, van acá.