Skip to main content

medOS Task

Background task and job scheduling — a lightweight worker node on the medOS service mesh.

medOS Task is a dedicated background worker in the medOS microservice mesh. Unlike the NestJS clinical and financial services, it is implemented in Go as a Moleculer node, joining the same NATS message bus under the shared core namespace. Its role is to host long-running and scheduled work — report generation, batch imports, scheduled reminders, and other asynchronous jobs — off the request/response path of the user-facing services.

Go
Implementation
Moleculer
Service framework
NATS
Transport
internal
Scope / port

Responsibilities​

  • Worker mesh membership — registers as a Moleculer node and discovers/serves actions over NATS, so other services can dispatch work by message rather than blocking HTTP calls.
  • Background job execution — designed to back long-running operations (report generation, batch imports, bulk exports) that should not occupy a synchronous API request.
  • Scheduling — a home for cron-style and reminder-driven jobs that fire on a timer rather than on a user action.
  • Async operation tracking — a place to model job lifecycle (queued, running, succeeded, failed) with retry and status callbacks to the originating service.
Implementation status

The service currently ships as a minimal Go/Moleculer node skeleton: it connects to the bus, publishes a task service, and stays resident as a worker. The responsibilities above describe the intended scope of the node. Treat job-queue, retry, and cron features as the design target for this service rather than a list of fully built endpoints — confirm against the source before integrating.

Major modules​

ModulePurpose
task (Moleculer service)The published service node; entry point that joins the mesh and exposes worker actions over NATS
Job executionRuns background / long-running operations dispatched from other services (intended)
SchedulingCron-style and reminder-driven timed jobs (intended)
Status trackingJob lifecycle, retry, and status-callback handling (intended)

How it fits the mesh​

The Task node is a peer of the other backend services. Callers do not reach it directly over HTTP; instead they emit work onto NATS, and Task picks it up as a Moleculer action or event. This keeps heavy or deferred work isolated from the latency-sensitive request path served by the Gateway.

 Clinical / Financial / Admin service
            │  (dispatch job over NATS)
            ▼
        ┌─────────┐
        │  NATS   │   core service mesh
        └─────────┘
            │
            ▼
     ┌──────────────┐
     │  medOS Task  │  Go / Moleculer worker
     │  (worker)    │
     └──────────────┘
            │  run · schedule · retry
            ▼
   report gen · batch import · reminders

Configuration notes​

The node is configured for the shared core namespace and connects to the cluster's NATS transport. It carries no public port and exposes no external REST surface — it is reachable only via the in-cluster message bus.

Joins NATS meshPublic REST surfaceExternal portPersistent worker

Several scheduling and queueing concerns elsewhere in medOS overlap with — and may eventually be backed by — this worker:

cron registryacknowledgement remindersauto-assign dispatchporter gig board
  • Cron registry — medOS maintains a DB-backed registry of scheduled jobs (see Architecture) so no schedule is invisible or unmanageable.
  • Acknowledgement reminders — recurring reminder/escalation chains for pending acknowledgements.
  • Auto-assign dispatch — event-driven assignment of tasks to staff/queues.
  • ANC-9 — Task Management System
  • ANC-8 — Porter Gig Board

See also​