OB_access: The Email Queue That Refuses to Forget

Most mailers optimize for throughput. OB_access optimizes for truth. It turns a campaign into a schedule that can be inspected, retried, and rebuilt, which is a very different promise from “send jobs into a queue and hope.”

The queue that rebuilds itself

The core idea is simple: the database owns the campaign state, not Redis. That means a Redis reset is annoying, but not fatal. If the queue drifts, the system can reconstruct it from Postgres and continue from the last known truth.

That design changes the emotional contract of the app. Instead of hiding delivery behind workers, it exposes the future as rows, timestamps, and states. The result feels less like a mailer and more like a delivery ledger with a repair loop.

Every email gets a time before it gets a job

The standout scheduling move lives in packSchedule. Rather than letting workers decide timing on the fly, the scheduler fans a campaign out into individual Email rows, assigns each one a scheduledAt, and writes them in a transaction.

That is a deliberate tradeoff. Precomputing the schedule gives users a clear campaign timeline, but it also means runtime checks still matter. The system chooses visibility first, then protects that visibility with recovery logic when conditions change.

// Conceptual shape of the scheduler
for (const recipient of recipients) {
  const scheduledAt = new Date(startAt.getTime() + offsetMs);
  await prisma.email.create({
    data: {
      campaignId,
      recipient,
      scheduledAt,
      status: 'SCHEDULED'
    }
  });
}

The claim-check-send pattern

The worker is disciplined about state transitions. A job is only claimed if the row is still SCHEDULED, which means competing workers can race but only one can win. That keeps duplicates from turning into chaos.

If a worker stalls or crashes, the system does not leave the row stranded forever. Stalled handling and recovery logic release the claim and let the campaign move forward again, which is exactly what you want from a delivery engine that expects failure.

Redis as an atomic gatekeeper

The rate limiter matters because it is atomic. The Redis Lua script checks and increments both global and per-sender counters in one operation, so workers cannot race each other into breaking the hourly ceiling.

When the limit is hit, the job does not fail. It slides into the next hour window. That is a practical compromise, and it fits the whole design philosophy of the project: preserve the campaign, preserve the order, preserve the intent.

Here the architecture makes its bet obvious. It prefers explicit state over hidden worker behavior, and it prefers a slightly delayed send over a broken one.

Reconciliation is the real superpower

The reconciler is what turns the system from robust into self-healing. On boot, it compares the database against Redis, finds scheduled emails that are missing jobs, and restores the queue from first principles.

That is the project’s real reliability trick. Redis is treated as an execution cache, not as the memory of the system. If Redis disappears, the campaign does not forget itself.

• Redis can vanish without erasing intent.
• Deterministic IDs make re-enqueueing safe.
• Scheduled rows in Postgres can repopulate the queue.
• The campaign resumes from state, not superstition.

Why this feels different from a normal mailer

Most email tools sell templates, analytics, and delivery volume. OB_access is more interested in temporal determinism, self-repair, and queue truth. That makes it feel closer to a durable task system than a marketing app.

That is why the project stands out. It does not merely send email. It makes delivery legible, then makes legibility durable.