A multi-tenant B2B platform needed to hand data to its customers on a schedule, without anyone on either side running a job by hand. What looked like a cron feature turned into four distinct problems: modelling the configuration, producing and tracking the artefact, holding someone else's credentials safely, and proving the whole path worked before calling it done.
One Profile as the Unit of Configuration
A single delivery profile answers four questions — what to send, where to send it, when, and on whose behalf. Keeping them on one record rather than spread across separate schedule, destination and filter tables meant a customer could reason about a delivery as one thing, and the system could enable or disable it atomically.
The schedule is stored as local wall-clock time plus a time zone, not as a UTC instant. A customer who asks for 06:00 means 06:00 where they are, across daylight-saving boundaries — resolving that to UTC at write time silently shifts the delivery twice a year.
Running It Across Replicas
Every application replica runs the same sweep loop. A single conditional UPDATE claims a due profile, so exactly one replica proceeds and the rest move on. That put the mutual exclusion in the database that was already there, rather than introducing a lock service and its failure modes.
Progress is tracked with a watermark rather than a window, so a run that is late or retried resumes from where the last successful one finished instead of silently skipping a period.
Two Destinations, Two Threat Models
Delivering to platform-managed storage is a question of streaming rows into a file and back out again without buffering the whole thing in memory. Delivering to a server the platform does not control is a different class of problem: it means storing a customer's credentials.
Those are write-only and encrypted, surfaced through a mask sentinel so the UI can distinguish 'unchanged' from 'cleared'. Host keys are pinned on first use and changes are surfaced rather than accepted. A profile cannot be enabled until a connection test has passed against the exact target that is stored — enforced on the server, not in the form.
The Delivery Log Is the Product
Support does not read application logs; they read the delivery history. Health is a state machine rather than a boolean, and connection failures carry the stage they failed at, because 'it did not work' is not actionable while 'authentication succeeded, the write failed' is.
Key Technical Decisions
Resolving to a UTC instant at write time breaks across DST.