Microservices
Scanly currently runs three dedicated microservice packages alongside the main backend:
- Automation Worker processes durable automation runs and coordinates their checkpoints with the backend.
- Mail Gateway sends prepared messages through AWS SES or the local Inbucket SMTP server.
- Frame Gateway provides the public HTTP and Socket.IO edge for live frame state.
The backend remains the owner of business data and Postgres persistence. The worker services receive small queue messages or TCP requests and ask the backend to perform operations that require domain data.
Architecture
Connection Summary
| Service | Receives work through | Calls or publishes to | Public endpoint |
|---|---|---|---|
| Automation Worker | BullMQ automations queue | Backend TCP RPC and external HTTP targets | None |
| Mail Gateway | BullMQ mail queue | BullMQ mail-results, AWS SES, or Inbucket | None |
| Frame Gateway | HTTP, Socket.IO, and backend TCP events | Backend TCP RPC and connected frame clients | HTTP and Socket.IO on port 3334 |
Service Boundaries
- Only the backend reads or writes automation and mail delivery records in Postgres.
- Template rendering, variable resolution, attachments, tracking preparation, and domain authorization stay in the backend.
- Valkey carries durable queue work. It is not the authoritative store for automation or delivery history.
- The Automation Worker does not call the Mail Gateway directly. A
SEND_MAILautomation action returns to the backend, which prepares and enqueues the mail request. - The Frame Gateway communicates directly with the backend over NestJS TCP because frame reads and updates need immediate request-response handling.