Core DevPre-alpha
Scale-out architecture
Sumeru runs as one or more stateless Go replicas behind a load balancer. Sessions live in PostgreSQL (sys.session), so any replica can serve authenticated requests without sticky cookies.
Phase 1 — production-shaped single cluster
| Knob | INI key | Purpose |
|---|---|---|
| Connection pool | db_max_open_conns, db_max_idle_conns, db_conn_max_lifetime_minutes | Avoid pool exhaustion under load |
| Read replica | db_read_replica_dsn | Route search / search_read / list views to replica |
| Rate limits | rate_limit_rpm | Per-IP cap on /api/rpc and /web/login |
| SMTP | smtp_host, smtp_port, smtp_from, … | Password reset and notifications |
Run N identical binaries behind nginx or HAProxy. Use /api/health for health checks.
Configure keys in Configuration (see sumeru.conf.example in the repo).
Phase 2 — async workers
- Outbox drain publishes to the in-process queue (
core/queue) afterevent.Publish; external brokers can subscribe to the same topic later. - Cron uses
FOR UPDATE SKIP LOCKEDonsys.cronso multiple instances do not double-run the same job. - Mail worker consumes the
mailqueue topic when SMTP is configured.
See Multi-instance cron for scheduler constraints.
Phase 3 — millions of concurrent reads
- Horizontal pod autoscaling on CPU/latency
- PgBouncer in transaction mode
- CDN for
/static/* - Separate API-only service if HTML render becomes the bottleneck
Writes remain bounded by the PostgreSQL primary; scale tenants with one database per tenant, not row sharding inside one ERP database.