DEV Community

Victor Laybats
Victor Laybats

Posted on Originally published at cascads.com

How we keep a social media scheduler from double-posting: a 200-process contention test

A social media scheduler has one job it must never get wrong: publish a post once. If two workers wake up for the same scheduled item at the same moment, a naive scheduler posts twice, and a duplicate on a client's account is worse than a late post.

In Cascads, a multi-brand social media cockpit, the guard is a durable claim: for one content item and one network key, exactly one process may call the provider while the claim is active. We wanted evidence that this holds under real contention, not just a passing unit test, so we measured it.

Method

Each round follows the same five steps:

  • Create a new temporary ledger for the round.
  • Start 8 independent Node.js processes and hold them at a common barrier.
  • Release the barrier so every process contests the same item and platform key.
  • Count callback marker files, which are written only inside the provider stub.
  • Require one delivered state, 7 blocked contenders and one callback in every round.

We ran 25 rounds, so 200 simultaneous attempts in total. The tested source is lib/publication-claims.js; the study page records its commit, its SHA-256 and whether it had uncommitted changes at test time.

Result

Every round satisfied the invariant. Across the 200 attempts, 25 workers reached the provider stub and 175 contenders were rejected before the side effect: 25 callbacks for 25 rounds, 0 duplicate callbacks and 0 unexpected worker outcomes.

What this does and does not show

This is narrow evidence about one local concurrency boundary. It is not evidence of customer outcomes, platform acceptance or distributed exactly-once delivery. In particular:

  • It is a controlled single-host process-contention study, not a production traffic sample.
  • The provider callback is a local deterministic stub: no social network API was called.
  • It does not test multi-host setups or distributed filesystems.
  • It covers the shared X and YouTube claim module through the X branch only.

If you build a scheduler, a queue consumer or anything that triggers an external side effect, this kind of barrier test is cheap to write and catches the race that unit tests never see.

Data

The summary, round-level results, schema and checksums are public under CC BY 4.0: the study page on cascads.com and the dataset in the IVRYN open research repository. No customer content, account identifier or credential is included.

Top comments (0)