Skip to main content

Deployment Topology

:::info Source Sourced from services/sync-service/DEPLOYMENT_TOPOLOGY.md in the documentation repo. :::

1. Containers

  • sync-api — REST sync protocol + admin API.
  • sync-delta-projector — consumes domain events; materializes deltas.
  • sync-push-router — routes mutations to owning services.
  • sync-health-monitor — tracks device health; cleans up stale data.
  • sync-outbox-relay.

2. Scaling

ContainerMinMaxHPA
api550CPU>60% or in-flight syncs > 200/pod
delta-projector320consumer lag > 10s
push-router320queue > 500
health-monitor13cron-driven
outbox-relay28backlog > 5000

3. Resources

api: 500m/2000m, 512Mi/2Gi. delta-projector: 500m/2000m, 512Mi/2Gi. push-router: 500m/2000m, 512Mi/2Gi.

4. Caching

  • Redis: cursor cache (reduce Postgres reads on pull), device-health cache, mutation dedup cache.

5. CDN

  • None (all authenticated, per-device).

6. Regional Deployment

  • Per region. Sync traffic pinned to tenant homeRegion.
  • Cross-region: if user travels, sync goes to nearest region → regional routing.

7. Service Mesh

  • mTLS.
  • Egress to every replicable service (push routing).
  • Ingress from client devices (via API gateway).

8. Release Strategy

  • Blue/green for api.
  • Rolling for projector + router (idempotent).
  • Delta table partition management automated.

9. DR

  • RPO 5 min (WAL + event log).
  • RTO 60 min.
  • Deltas rebuildable from domain event log.
  • Cursors rebuildable from client state (devices re-sync).

10. Diagram

Client device ──HTTPS──▶ API Gateway ──▶ sync-api

┌──────────┼───────────┐
│ │ │
/push /pull /ack
│ │ │
▼ │ ▼
sync-push-router │ cursor UPDATE
│ │
┌─────────────┼─────────┐│
│ │ ││
progress assessment authoring ││
(push-handler) │▼
deltas table (read)

Domain events ──▶ NATS ──▶ sync-delta-projector ──▶ deltas table (write)