Corey — plataforma bedbank B2B

Qué es

Corey es la plataforma bedbank B2B que estamos construyendo en Nextay. Un bedbank actúa como intermediario mayorista: agrega inventario de alojamiento de una parte y lo distribuye a clientes de la otra. Eso significa que la plataforma tiene que servir a dos públicos con necesidades opuestas, además de al equipo interno que la opera.

De ahí que no sea una aplicación, sino tres superficies sobre un mismo núcleo:

• Extranet de proveedores — donde los proveedores cargan y mantienen su inventario, disponibilidad, tarifas y condiciones.
• Extranet de clientes — donde los clientes consultan, reservan y gestionan sus operaciones.
• Intranet — la herramienta interna de gestión, control y soporte de toda la operativa.

La decisión de fondo

La tentación con tres superficies es construir tres aplicaciones. Funciona al principio y se paga después: la misma regla de negocio acaba implementada tres veces, con tres interpretaciones ligeramente distintas, y el día que cambia una condición comercial hay que ir a buscarla a tres sitios.

El planteamiento es el contrario. Las reglas —qué es disponibilidad válida, cómo se calcula una tarifa, qué transiciones de estado admite una reserva— viven una sola vez en el núcleo. Cada extranet es una vista sobre ese núcleo con sus propios permisos y su propio lenguaje.

Capa de integración

Un bedbank no vale nada aislado: su utilidad está en estar conectado. Por eso la plataforma expone y consume webservices y APIs que la enlazan con proveedores y clientes del sector, cada uno con su propio protocolo, su modelo de datos y su nivel de fiabilidad.

Aquí se aplica lo aprendido en integraciones anteriores: la complejidad de cada tercero se aísla en su propio adaptador, y hacia dentro se habla siempre un único lenguaje. Cuando un proveedor cambia su formato, se toca un archivo, no toda la aplicación.

El presupuesto de latencia

Al ser B2B, del otro lado de la API no hay una persona esperando: hay sistemas que consultan de forma automática y encadenan nuestra respuesta con las suyas. Eso cambia por completo lo que significa “rápido”.

La plataforma responde en 20 ms o menos. No porque un usuario note la diferencia entre 20 y 200 ms, sino porque nuestra respuesta es un eslabón dentro de la cadena de otro: lo que tardemos se suma a su propio presupuesto de tiempo, y si nos pasamos, el problema aparece en su plataforma, no en la nuestra.

El umbral crítico está en 1.000 ms. Llegar ahí no es “ir lento”: es que un cliente integrado empiece a acumular timeouts y a degradar su servicio por nuestra causa. Por eso la latencia no se trata como una métrica de rendimiento a mejorar cuando haya tiempo, sino como parte del contrato.

Sostener ese número condiciona decisiones que en un producto B2C no tomarías igual: qué se precalcula y qué se resuelve en la petición, qué vive en caché, y hasta dónde se puede permitir una llamada a un tercero dentro del camino crítico. Una consulta que dependa de la respuesta de un proveedor externo no cabe en 20 ms, así que o está resuelta antes de que llegue la petición o no está en ese camino.

Stack y por qué

Laravel con Octane donde el rendimiento importa. Octane mantiene la aplicación en memoria entre peticiones y elimina el coste de arranque del ciclo tradicional de PHP. En las rutas de consulta —las que se llaman constantemente— esa diferencia es la que separa una respuesta cómoda de una que se nota.

Vue 3 con Quasar para las tres superficies de interfaz. Quasar aporta un catálogo de componentes consistente, lo que permite que extranets e intranet se sientan parte del mismo producto sin rehacer el sistema de diseño tres veces.

MySQL, Docker y Terraform como base de datos, entorno reproducible e infraestructura declarada en código.

Estado

En desarrollo activo. Es el proyecto que ocupa la mayor parte de mi trabajo técnico actual.