Case study · Own product · pre-launch
EscapaYa
An hourly hotel booking marketplace with APIs, payments and notifications.
The problem
There are hotels with rooms available that barely exist online.
How do we make finding and booking a few hours simple?
EscapaYa brings together hourly bookings, payments, geolocation and notifications. The backend connects these operations with the Flutter app and background processes.
Context
An own product, built end to end: app, web, API, payments and notifications. It is pre-launch, so this page is about decisions, not metrics.
My role
Product, architecture and code: scoping it, designing the architecture and building backend, app and web.
Constraints
- Retries and idempotency for critical operations.
- Availability by the hour, finer than a nightly booking.
- Payments and notifications connected through APIs and asynchronous processes.
- Mobile first: booking happens on the phone.
Architecture
An explanatory diagram based on the product stack. Its flows illustrate how APIs, data, queues and notifications connect. Tap a component to understand its purpose.
App · Flutter
- What it solves
- The booking app for Android and iOS.
- Why it exists
- One codebase for both platforms. Booking a few hours happens on the phone, often the same day.
- What else was on the table
- Two native apps: twice the work for a small team.
Web · Next.js
- What it solves
- The public site: search, hotel pages and pages for search engines.
- Why it exists
- People looking for a hotel by the hour arrive from Google: the pages have to exist for search engines.
- What else was on the table
- A client-only SPA: invisible to SEO.
Edge · Cloudflare
- What it solves
- The front door: caching, TLS and a first layer against abuse.
- Why it exists
- Images and pages close to the user, without loading the server with what does not change.
- What else was on the table
- Serving everything from the origin.
API · NestJS
- What it solves
- One entry point for app and web: authentication, validation and the rules of every request.
- Why it exists
- Clear modules inside one application: it deploys and runs as a single piece.
- What else was on the table
- Microservices from day one: too much to operate for a product before launch.
Bookings · NestJS modules
- What it solves
- The domain: hotels, rooms, hourly availability and bookings.
- Why it exists
- The hard rule lives here: two people never book the same room for the same hour.
- What else was on the table
- Logic in database procedures: hard to test and to change.
Database · PostgreSQL · Prisma
- What it solves
- The source of truth: hotels, rooms and bookings.
- Why it exists
- Transactions and constraints so a booking is never duplicated.
- What else was on the table
- A NoSQL store: more flexible, without the guarantees a booking needs.
Cache · Redis
- What it solves
- What is read often and changes little: recent availability, sessions.
- Why it exists
- Answers fast without hitting the database on every search.
- What else was on the table
- Always going to the database.
Files · Object storage
- What it solves
- Photos of hotels and rooms.
- Why it exists
- Big files out of the database, served by the edge.
- What else was on the table
- Keeping them on the server: it does not scale and complicates every deploy.
Queues · BullMQ
- What it solves
- Work that does not belong in the request: confirmations, reminders, expirations.
- Why it exists
- Nobody waits for a message to go out, and failures retry on their own.
- What else was on the table
- Cron and polling, or a separate broker. BullMQ reuses Redis, already there.
Notifications · FCM · WhatsApp
- What it solves
- Messages to the guest and to the hotel.
- Why it exists
- An hourly booking is immediate: the hotel has to know right away.
- What else was on the table
- Email only: it arrives late and nobody reads it in time.
Payments · Payment provider
- What it solves
- Charging for the booking, through a payment provider.
- Why it exists
- A certified third party handles the money; the API only keeps the payment status.
- What else was on the table
- Paying at the hotel: more friction and more no-shows.
Results
Pre-launch. No public metrics yet: when there is real data, it goes here.