How we built a publishing engine that never drops a post

A look under the hood at durable workflows, idempotent queues and automatic retries.

Most schedulers treat publishing as a cron job — fire and forget. That works right up until the moment it doesn't, usually during a launch. We built ours the opposite way: assume every step can fail, and make failure recoverable.

Durable workflows

Every scheduled post runs as a durable workflow. If a step throws — a rate limit, a network blip, an expired token — the workflow pauses and resumes exactly where it left off, instead of silently dying.

Idempotent queues

Retries are only safe if they can't double-post. Each publish carries an idempotency key, so a retried request that already succeeded becomes a no-op. You get at-least-once delivery with exactly-once results.

The payoff

The result is boring, in the best way: posts go out when you scheduled them, and when something upstream breaks, the system heals itself and keeps a full, searchable audit trail of what happened.