Ghasi Melmastoon
In development · pre-launch
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
- 2024 — present
- Domain
- Hospitality / PMS
- Stack
- NestJS
- Drizzle
- Postgres + RLS
- GCP Pub/Sub
- Argon2id
Hospitality PMS is a fragmented market with old-stack incumbents.
Melmastoon is the multi-tenant, event-driven take: independent guest booking apps per tenant, a desktop back-office for staff with offline sync, and a service mesh built on the same conventions as the rest of the Ghasi platform.
Anonymized to remove proprietary details. The pattern is real; the specifics aren't the part that matters here. Hover any layer label for context.
— 01 —
Tenant isolation via Postgres RLS + per-request GUC, not application-level filtering.
CostEvery transaction sets the GUC.
WinCross-tenant reads are structurally impossible.
— 02 —
Live-vs-spec drift gate in CI.
CostA CI step.
WinThe spec is always the truth; OpenAPI drift fails the PR via oasdiff.
— 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.
— 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.
- 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.
Founder, lead architect, primary contributor.
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.