Hospitality · Nuxt.js + .NET 10 · Technical lead
A shared booking platform for seven hospitality brands.
Nuxt.js brand experiences backed by a shared .NET 10 booking API serving seven brands and approximately 100,000 bookings per month.
- Role
- Full-stack platform architecture, API design, phased migration and delivery leadership
- Technology
- Nuxt.js · .NET 10 · Azure SQL · Dapper · Azure WebJobs
01 / Background
Context
Distinct Nuxt.js brand experiences made venue discovery, menus and bookings accessible across a national hospitality estate. Behind those journeys, seven brands depended on a shared legacy Java API. The platform needed a maintainable booking core that could evolve independently while continuing to support each brand’s customer experience.
02 / Constraints
Constraint
Replacing the entire platform at once would have put live booking journeys at risk. The Java-to-.NET migration had to move capabilities in phases, preserve brand-specific Nuxt.js experiences and integrate content, menus, availability, fulfilment and CRM services without compromising booking integrity.
03 / Change
Before / after
Nuxt.js brand experiences relied on a shared legacy Java API whose breadth and coupling made change harder for the team to own and deploy.
A brand-aware .NET 10 booking API introduced clear service boundaries, SQL-managed configuration, resilient integrations and an independently deployable Azure platform.
04 / Architecture
System design
- 01
Nuxt.js brand experiences
Distinct venue, menu and booking journeys for national brands
- 02
.NET 10 booking API
Brand-aware orchestration, JWT security, validation and integrations
- 03
Azure data + operations
SQL transactions, WebJobs, caching, recovery and observability
05 / Decisions
Technical decisions
- 01
Migrate by business capability
Move bookings first, then content and remaining services, so each phase created value without forcing a risky platform cutover.
- 02
Make brand context explicit
Use request-level brand context with SQL-managed per-brand configuration so one API could serve seven brands without scattered conditional logic.
- 03
Protect booking integrity
Combine traceable journey keys with database transactions to prevent duplicate submissions and commit complete multi-record operations or roll them back.
- 04
Plan for recovery and diagnosis
Add bounded retries, background recovery, health checks, caching, Application Insights and Sentry so production failures were visible and recoverable.
06 / Leadership
My contribution
I selected .NET 10, secured approval for the phased migration and architected and built most of the API. I translated client requirements into platform boundaries, guided developers, led delivery across teams of up to four and acted as an escalation point for architecture, debugging and production incidents.
07 / Results
Outcome
The shared API now serves seven brands and approximately 100,000 bookings per month. Critical workflows maintained approximately 80% unit-test coverage, Azure DevOps pull-request validation ran the full suite, and YAML pipelines supported Test, UAT and Production releases.