Everything an evaluator needs to sign off.

Architecture

Four clients sit on top of Next.js BFFs that fan out to 22 Rust microservices. Each service owns its own data; cross-service reads only happen over the public API. Real-time updates flow over a shared event bus exposed as Server-Sent Events. Postgres-per-property gives tenants hard data isolation.

Stack

No proprietary runtimes, no closed-source databases. Everything is community-supported, well-instrumented, and easy to fork.

Service catalog

22 Rust microservices, each with a single bounded context. Ports below match the production deployment (one systemd unit per service).

API reference

REST + JSON over HTTPS. Every mutating endpoint requires a JWT (cookie or Authorization: Bearer). Every read endpoint returns a consistent envelope.

Response envelope

{
  "success": true,
  "data": { ... },        // shape varies per endpoint
  "meta": { "page": 1, "total": 42 }  // optional
}

Auth

POST /auth/login
// Body
{
  "email": "[email protected]",
  "password": "…",
  "property_id": "00000000-0000-…"
}
// 200 → sets HttpOnly access_token + refresh_token cookies

Common patterns

OpenAPI

Each service exposes its own OpenAPI 3.1 doc generated from its Rust types via utoipa. The merged spec for the BFF is published at /api/openapi.json; the per-service docs live at :port/swagger-ui/.

Real-time (SSE)

Live updates use Server-Sent Events because they're a one-way fan-out, work through standard proxies, and need no protocol upgrade. Behind each stream is a topic-based tokio::sync::broadcast channel — slow subscribers are dropped, never block fast ones.

Subscribing

GET /api/v1/properties/:id/messaging/staff/channels/:cid/stream
// Server keeps the connection open; events look like:
event: created
data: {"id":"…","content":"Towels for villa 12","sender_name":"Aisha"}

event: updated
data: {"id":"…","status":"acknowledged"}

: keep-alive   // every 15s, ignore

Client (Flutter)

// staff_app/lib/services/sse_client.dart
SseClient.instance
  .subscribe(
    '/api/v1/properties/$propertyId/transfers/stream',
    auth: authService,
  )
  .listen((evt) {
    // evt.event ∈ {'created','updated','deleted'}
    // evt.json carries the entity
  });

Topics shipping today

• chat::<property_id>::<channel_id>
• transfers::<property_id>
• supply_requests::<property_id>
• incidents::<property_id>
• room_service::<property_id>

Data & tenancy

Database-per-property tenancy. Each property has its own Postgres instance behind a control-plane registry. Cross-property queries go through analytics-service, which has read-replica access to all of them.

How a request resolves

1. Client sends a request with a JWT.
2. Service decodes the JWT and extracts property_id.
3. shared_lib::tenant_pool looks up the connection string in the control-plane DB.
4. The request executes against that property's pool.

Migrations

Each service ships its own migrations/ directory. On boot, sqlx::migrate!() runs against the connected pool. guest-services-service additionally falls back to in-memory mode when no DATABASE_URL is set, so the demo runs offline.

Backups

Velero schedules pg_dump per tenant nightly. Restore drills are part of the launch readiness checklist (see Phase 23 in LAUNCH_READINESS_PLAN.md).

Self-hosting

Two paths: Docker Compose for evaluation and dev, Kubernetes (Helm + Argo Rollouts) for production.

1 · Docker Compose (5 minutes)

git clone https://github.com/your-org/guest-journey
cd guest-journey
cp env.example .env
docker compose -f docker-compose.dev.yml up -d
./dev-start.sh   # builds + runs every service

Hits localhost:8000 for the dashboard, localhost:8080 / :8090 for the Flutter web builds.

2 · Kubernetes

helm repo add guest-journey https://charts.your-org.example
helm install gj guest-journey/platform \
  --set postgres.host=… \
  --set redis.host=… \
  --set objectStorage.endpoint=…

Manifests are in k8s/; the chart wraps them with sensible defaults and Argo Rollouts annotations for canary deploys.

Required env

Observability

OpenTelemetry traces, Prometheus metrics, structured logs. Every service exposes /health, /metrics, and labelled spans on every handler.

What's wired

• Prometheus scrape configs and Grafana dashboards in infrastructure/grafana/
• OTLP traces over gRPC; sampling configurable per service
• SLO templates and burn-rate alerts in Alertmanager
• Falco runtime rules under compliance/runtime/
• k6 load profiles for 5 critical journeys

Default SLOs

Testing & quality

Tests are first-class; the launch checklist gates promotions on coverage and end-to-end pass rate.

Contributing

Issues, PRs, and discussions welcome. The repo is an Apache-2.0 monorepo. The codebase is opinionated but the conventions are documented.

• CONTRIBUTING.md — development setup, commit style, review rules
• ARCHITECTURE-TENANCY.md — multi-tenant data model
• SECURITY.md — disclosure process
• GitHub repo — stars welcome

Open the repo on GitHub → Talk to us