Skip to content
Asmar.
§ CS-04 — Ghasi Melmastoon

Ghasi Melmastoon

In development · pre-launch

  • · AI-first by design
  • · Offline-first by design

Multi-tenant property management system for hospitality. 21 services planned, sharing a common pattern with the rest of the Ghasi suite — same DDD posture, same outbox discipline, different domain.

Period
2025 — present
Domain
Hospitality / PMS
Stack
  • API Gateway · IAM
  • Per-surface BFFs
  • Relational + RLS
  • GCP · Pub/Sub
  • AI Gateway
  • DDD · Outbox
The brief

Hospitality PMS is a fragmented market with old-stack incumbents. Staff operate under real-world constraints: unreliable in-property Wi-Fi, high-pressure shift handovers, and zero tolerance for systems that require a live network call to function.

Melmastoon is the multi-tenant, event-driven, offline-first and AI-first take on that problem: independent guest booking apps per tenant, a desktop back-office that keeps running and reconciling when the network is down, and AI-powered features — dynamic pricing hints, guest communication drafts, demand forecasting — routed through a single AI Gateway with provenance metadata on every generated artifact.

Architecture at a glance

The layers, ports, and integration patterns are real — drawn from the live architecture baseline. Service names, identity providers, and external vendors are anonymized or labelled by role so the diagram reads as the posture, not as a deployment manifest. Hover any layer label on the left for context; right-edge annotations call out the load-bearing decisions.

Decisions & tradeoffs
  1. 01

    Tenant isolation via row-level security at the relational layer + per-request tenant context variable, not application-level filtering.

    CostEvery transaction sets the tenant context.

    WinCross-tenant reads are structurally impossible.

  2. 02

    Live-vs-spec drift gate in CI.

    CostA CI step.

    WinThe spec is always the truth; OpenAPI drift fails the PR via oasdiff.

  3. 03

    Desktop client owns its outbox and sync loop in-process.

    CostMore client-side code.

    WinThe back-office keeps working when the network doesn't; conflicts resolve via vector clocks.

  4. 04

    Same template as the rest of the Ghasi suite (`iam-service`).

    CostThe template has to be good.

    WinEvery new service is a copy-paste with domain swap, not a new architectural decision.

Outcome & scope
  • Wave 4: end-to-end guest registration wired, 20 services ahead.
  • Standards enforced by ESLint, commitlint, contract tests, security audits, Renovate.
  • Pre-launch deployment in preparation for first hospitality partner.
My role

Founder, lead architect, primary contributor.

What I'd do differently

The first cut of `bff-consumer-service` tried to be both an anonymous search BFF and a guest-auth proxy. Splitting that responsibility was the right call but cost a refactor.

← All case studies

Designing something similar?

Explore other work