Architecture
How the server, the store and the workers fit together, and what is safe to scale horizontally.
A Sextant deployment has three parts: a server, a store and one or more workers. Clients (the CLI, the SDKs, your own HTTP calls) only ever talk to the server.
The server
sextant server runs the HTTP API and the scheduler in one process. It validates requests, checks token scopes, writes to the store, and ticks the scheduler once per second to turn due schedules into jobs. The server keeps no state in memory that matters: you can restart it at any time, and you can run several behind a load balancer when the store is Postgres.
The store
The store is the single source of truth: jobs, attempts, schedules, tokens and leases. Workers do not talk to each other, and the server does not push jobs to workers. A worker asks the store for the next runnable job, using a row-level lock so that two workers never take the same job.
Workers
A worker is any process that pulls jobs: sextant worker for command handlers, or your own application using an SDK. Workers are the part you scale for throughput. They are safe to start, stop and kill; see Deploying for graceful shutdown.
Events out
Three things leave the system: webhooks to your endpoints, Prometheus metrics on a separate port, and structured logs on standard output. See Observability.
What scales how
| Part | Scale by | Limit |
|---|---|---|
| Workers | Adding processes | The store’s connection limit |
| Servers | Adding processes (Postgres only) | One scheduler is active at a time, chosen by an advisory lock |
| Store | Vertical, then read replicas for dashboards | Write throughput of one primary |