Cloud Backend

The Cloud Backend is the central API server for the Monozu Cloud platform. It serves the Cloud SPA, handles Edge device communication, runs background jobs, and exposes internal M2M endpoints for the Management service.

Tech stack

Component	Technology
Language	Go 1.26
HTTP framework	Fiber v3 (fasthttp)
Database client	sqlx (manual SQL, no ORM)
Database	Azure SQL Server (MSSQL)
Auth	JWT (HS256), bcrypt, TOTP, OIDC
Logging	zerolog (structured JSON)
Observability	OpenTelemetry → Azure Application Insights
Migrations	Flyway (V1–V28)

Entry point

Backend/
├── cmd/
│   ├── api/main.go        # HTTP API (Fiber)
│   └── worker/main.go     # Background schedulers + job queue consumer (ACA split)
├── internal/
│   ├── app/               # Wiring: DI, route registration
│   ├── domain/            # ~35 bounded context packages
│   ├── db/                # sqlx setup, models, RLS helpers
│   ├── middleware/         # Auth, RBAC, logging, recovery
│   ├── services/          # Shared cross-domain services
│   ├── jobs/              # Background job runners
│   ├── websocket/         # WebSocket hub and handlers
│   └── rbac/              # Permission catalog
├── db/
│   └── migration/         # Flyway SQL files (V1–V28)
└── go.mod

Route registration

All API routes are registered in internal/app/register_*.go files. Each file corresponds to a domain or feature group. Routes share the /api/v1 prefix.

File pattern	Routes registered
`register_auth.go`	`/api/v1/auth/*`
`register_assets.go`	`/api/v1/assets/*`
`register_incidents.go`	`/api/v1/incidents/*`
`register_security.go`	`/api/v1/security/*` (optional)
`register_internal.go`	`/internal/license/refresh`
…	…

Handler pattern

Every domain follows: handler → service → repository (sqlx)

domain/<name>/
├── handler.go    # HTTP handler, input parsing, response marshalling
├── service.go    # Business logic, cross-domain calls
└── repository.go # sqlx queries against Azure SQL

Handlers are thin: they parse and validate input, call the service, and write the response. Business logic lives in the service layer.

Background jobs

Scheduled work and async tasks use internal/jobs/:

Process	When	Role
`cmd/api`	Local dev (no `AZURE_STORAGE_ACCOUNT_JOBS`)	HTTP + in-process schedulers + memory queue
`cmd/api`	ACA `cloud` app	HTTP only; enqueues to Azure Storage Queue
`cmd/worker`	ACA `worker` app	Schedulers + Azure queue consumer (no HTTP)

Queue transport: in-memory channel locally; Azure Storage Queue (AZURE_STORAGE_ACCOUNT_JOBS, default queue jobs) in split mode. Job payloads are JSON envelopes (type + payload).

Job type	Purpose
CVE feed sync / vuln scan	Catalog sync, CPE match, tenant scans
Audit log retention	Delete `audit_logs` past tenant retention
Tool execution / backup	Async security tools, backup collection
Notification delivery	Integration webhook/email dispatch (ACS Email)