Batching Transactional Emails With Redis SETNX and a Digest Endpoint | AI PM Portfolio

Batching Transactional Emails With Redis SETNX and a Digest Endpoint

April 11, 2026 · 9 min read · AI for Solo Founders

Last Updated: 2026-04-11

Redis SETNX with a TTL solves transactional email spam by atomically claiming a batch window. When the first event fires, SETNX locks a key for 60 seconds and schedules a digest endpoint. Subsequent events during the window are silently absorbed. The digest endpoint collects all events in the window and sends one email. This pattern reduced our notification volume by 85% and eliminated a 13-duplicate-email incident without adding queues or external dependencies.

Why does "1 event = 1 email" break at scale?

Most transactional email systems start with a simple rule: when something happens, send an email. Upload a document, get a confirmation. Place an order, get a receipt. This works until users perform the same action in rapid succession.

In a document processing platform I built, users routinely upload 5-15 files in a single session. Each upload triggers an extraction pipeline, and each successful extraction fires a "documents received" notification. The result: a user uploading 8 tax documents in 45 seconds receives 8 separate emails. One tester uploaded 19 documents during onboarding and received 13 "documents received" emails in 2 minutes and 31 seconds. Three other users hit the same bug within 24 hours -- one received 9 duplicates, another received 4.

According to Email Tool Tester's 2025 deliverability report, sending more than 5 emails to the same recipient within 10 minutes increases the probability of spam classification by 340%. Mailgun's 2024 data shows that transactional email open rates drop from 68% to 23% when users receive more than 3 emails from the same sender in an hour. Email spam is not just annoying -- it actively degrades deliverability for every subsequent message you send.

Why didn't in-memory debouncing work on serverless?

The first fix attempt used an in-memory Map to track recent notifications:

// BROKEN on serverless -- each invocation gets a fresh Map
const _recentNotifications = new Map<string, number>();

function shouldSendEmail(userId: string, type: string): boolean {
  const key = `${userId}:${type}`;
  const lastSent = _recentNotifications.get(key);
  if (lastSent && Date.now() - lastSent < 60_000) {
    return false; // suppress duplicate
  }
  _recentNotifications.set(key, Date.now());
  return true;
}

On a traditional long-running server, this works. On Vercel or AWS Lambda, each function invocation spins up a fresh runtime. The Map is empty on every cold start. Seven uploads hitting seven separate function invocations means seven empty Maps, zero deduplication, and seven emails. According to Vercel's own documentation, serverless functions have no shared memory between invocations. Any in-process state is ephemeral.

This is a fundamental constraint of serverless architectures: you cannot rely on in-memory state for coordination across requests. You need an external store. I covered a similar infrastructure constraint when optimizing AI inference costs -- the pattern of moving coordination out of application memory and into shared infrastructure applies broadly.

How does Redis SETNX solve the batching problem?

Redis SETNX (SET if Not eXists) is an atomic operation. It sets a key only if the key does not already exist, returning true on success and false if the key was already set. Combined with a TTL, it creates a self-cleaning batch window with zero race conditions.

Step 1: Claim the batch window

When any event fires that would trigger an email, attempt a SETNX on a batch key:

import { Redis } from "@upstash/redis";

const redis = new Redis({
  url: process.env.UPSTASH_REDIS_URL!,
  token: process.env.UPSTASH_REDIS_TOKEN!,
});

const BATCH_WINDOW_SECONDS = 60;

async function claimBatchWindow(
  userId: string,
  emailType: string
): Promise<boolean> {
  const key = `email:batch:${userId}:${emailType}`;
  // SETNX + EX is atomic -- no race between set and expire
  const claimed = await redis.set(key, Date.now(), {
    nx: true,           // only set if key doesn't exist
    ex: BATCH_WINDOW_SECONDS, // auto-expire after 60s
  });
  return claimed === "OK"; // true = we claimed it, false = already claimed
}

The nx: true flag makes this atomic. If 8 uploads hit 8 separate Lambda invocations simultaneously, exactly one will get "OK". The other 7 get null. No race condition, no locks, no distributed mutex. Redis handles the serialization at the protocol level -- the SET with NX is a single command processed in Redis's single-threaded event loop.

Step 2: Schedule the digest

Only the invocation that claimed the window schedules the digest:

// Inside the upload/extract handler
const isBatchLeader = await claimBatchWindow(userId, "documents_received");

if (isBatchLeader) {
  // Schedule a digest call after the batch window closes
  // The digest endpoint will collect all events in the window
  await fetch(`${process.env.APP_URL}/api/internal/email-digest`, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "x-internal-secret": process.env.INTERNAL_API_SECRET!,
    },
    body: JSON.stringify({
      userId,
      emailType: "documents_received",
      batchWindowSeconds: BATCH_WINDOW_SECONDS,
    }),
  });
}
// If not the batch leader, do nothing -- the digest is already scheduled

Step 3: The digest endpoint collects and sends

// app/api/internal/email-digest/route.ts
import { NextRequest, NextResponse } from "next/server";

export const maxDuration = 90; // Vercel Pro: allow time for the delay

export async function POST(req: NextRequest) {
  // Verify internal secret
  const secret = req.headers.get("x-internal-secret");
  if (secret !== process.env.INTERNAL_API_SECRET) {
    return NextResponse.json({ error: "Unauthorized" }, { status: 401 });
  }

  const { userId, emailType, batchWindowSeconds } = await req.json();

  // Wait for the batch window to close
  // All uploads during this window will be captured
  await new Promise((resolve) =>
    setTimeout(resolve, (batchWindowSeconds + 5) * 1000) // +5s buffer
  );

  // Query all events that occurred during the window
  const { data: documents } = await supabase
    .from("document_extractions")
    .select("file_name, doc_type, created_at")
    .eq("user_id", userId)
    .gte("created_at", new Date(Date.now() - (batchWindowSeconds + 30) * 1000).toISOString())
    .order("created_at", { ascending: true });

  if (!documents || documents.length === 0) {
    return NextResponse.json({ skipped: true });
  }

  // Send ONE email listing all documents
  await sendBatchedEmail({
    to: userId,
    subject: `Your ${documents.length} documents have been received`,
    fileNames: documents.map((d) => d.file_name),
    docTypes: documents.map((d) => d.doc_type),
  });

  // Log to email_log for dedup and audit
  await logEmail({
    client_user_id: userId,
    trigger: emailType,
    subject: `Batch: ${documents.length} documents received`,
    sent_at: new Date().toISOString(),
  });

  return NextResponse.json({ sent: true, count: documents.length });
}

The result: 8 uploads produce 1 email that says "Your 8 documents have been received" with a list of all file names. The user gets a useful summary instead of inbox noise.

Why is the email_log table critical for the second layer of dedup?

Redis SETNX handles batching within a window. But what about edge cases -- retries, network failures, or the digest endpoint being called twice? The email_log table provides a second layer of defense.

Every sent email is recorded in email_log with the user ID and trigger type. Before sending, the digest endpoint checks if this email was already sent:

// Check email_log before sending
const { count } = await supabase
  .from("email_log")
  .select("id", { count: "exact", head: true })
  .eq("client_user_id", userId)
  .eq("trigger", emailType)
  .gte("sent_at", new Date(Date.now() - 5 * 60 * 1000).toISOString());

if ((count ?? 0) > 0) {
  // Already sent within the last 5 minutes -- skip
  return NextResponse.json({ skipped: true, reason: "dedup" });
}

Here is the critical lesson from production: the 13-duplicate-email incident happened because the email_log was never written on successful sends. The dedup check queried email_log for prior sends, found zero rows (because nothing was ever logged), and approved every send. The dedup check was technically correct code that was functionally dead.

// THE BUG: SEND branch never logged
switch (result.decision) {
  case "SEND":
    await sendFn();    // sends the email
    break;             // NEVER writes to email_log <-- BUG
  case "DELAY":
    await queueDelayed(input);  // writes to email_log
    break;
  case "SUPPRESS":
    await logSuppression(input); // writes to email_log
    break;
}

The DELAY and SUPPRESS branches logged correctly. The SEND branch -- the one that actually delivers emails to users -- did not. This is a class of bug I call "success path blindness": error and edge-case paths get careful attention during code review, while the happy path is assumed to work and skipped. The fix was a single line: await logEmail(input) after await sendFn().

How does SETNX batching compare to other dedup approaches?

The email_log-only approach has a Time-of-Check-to-Time-of-Use (TOCTOU) race: two parallel invocations both query email_log, both find zero rows, both proceed to send. This is exactly what happened in the 13-duplicate incident. Even with the email_log write fixed, parallel extractions finishing within 100ms of each other would still produce 2-3 duplicates.

SQS FIFO with content-based deduplication solves the race condition but introduces a new dependency, costs ($0.35 per million messages after the free tier), and requires a consumer function to aggregate events into digests. For most solo-founder or small-team products, Redis SETNX is the right balance of correctness and simplicity. When scaling processing pipelines, the queue approach becomes worthwhile -- but start simpler.

What are the implementation details that matter?

TTL selection

The batch window TTL depends on user behavior. I analyzed 74 user sessions and found that 92% of multi-document uploads complete within 45 seconds. Setting the TTL to 60 seconds captures the long tail while keeping email latency under 2 minutes. For e-commerce order confirmations, you might use 5-10 seconds. For CI/CD build notifications, 5-10 minutes makes sense.

The digest endpoint needs maxDuration

On Vercel, the default function timeout is 10 seconds. A digest endpoint that sleeps for 60 seconds will be killed at 10. You must set maxDuration on the route to at least the batch window plus buffer. On Vercel Pro, the maximum is 300 seconds. On Hobby, it is 60 seconds -- which means a 45-second batch window is the practical limit.

Trigger string consistency

The email gate dedup checks email_log for matching trigger values. If the batch scheduler passes "documents_received" but the log writer records "doc_upload", the dedup query finds nothing and cannot prevent duplicates. I discovered this exact mismatch in a status notification system -- the gatedSend function used the actual status string (like "walked_away") while logEmail hardcoded "status_update". It took 21 duplicate emails to one user in 36 hours before the bug was caught.

Log before or after send?

For batched digest emails, log after send. If the email fails, you want the system to retry on the next batch window. For high-frequency drip or nurture emails where duplicate prevention is more important than guaranteed delivery, log before send (the "reservation pattern"). This way, if the send fails, the log entry prevents a retry -- which is preferable to sending duplicates of a marketing email.

What is the broader pattern for notification batching?

Any system where "1 event = 1 notification" should be evaluated for batching. The test is simple: can a user trigger the same event type more than once within 60 seconds? If yes, you need batching.

Common candidates beyond document uploads:

• Chat messages -- batch "new message" push notifications when a conversation is active
• CI/CD builds -- batch commit notifications into a single "3 builds completed" email
• E-commerce inventory -- batch "back in stock" alerts when restocking multiple SKUs
• Monitoring alerts -- batch threshold violations into a single incident summary
• Collaborative editing -- batch "document updated" notifications during active editing sessions

The SETNX pattern works for all of these. The only variables are the TTL (based on typical burst duration), the digest query (what events to aggregate), and the email template (how to present a list of events as a single coherent notification).

According to AWS SES documentation, batching transactional emails reduces API calls by 60-80% in typical SaaS applications, which directly lowers both cost and the risk of hitting rate limits. Resend, the email provider I use, enforces a 10 requests per second rate limit on the free tier. Without batching, a user uploading 15 documents would fire 15 API calls in under 30 seconds -- hitting a 429 rate limit error and failing to deliver any emails at all.

The one-line summary: If your email system sends one notification per event, you are one power user away from a spam incident. Redis SETNX with a 60-second TTL and a digest endpoint is the lowest-complexity fix that is both race-safe and serverless-compatible.

Frequently Asked Questions

Can I use a database instead of Redis for the SETNX pattern?

Yes, but with caveats. PostgreSQL's INSERT ... ON CONFLICT DO NOTHING provides similar atomic semantics. However, database writes are 5-10x slower than Redis operations (2-5ms for Redis vs 20-50ms for Postgres), and you need to manage TTL cleanup yourself via a cron or scheduled function. For email batching, the performance difference is negligible. For high-throughput event systems processing thousands of events per second, Redis is the better choice.

What happens if the digest endpoint fails after the SETNX key expires?

The batch window closes, the Redis key expires, and the next event will claim a new window and schedule a new digest. Any events from the failed window will be picked up by the new digest's query (since it looks back at recent events by timestamp, not by batch ID). In the worst case, the user receives two emails -- one for the failed batch and one for the new batch -- which is still better than 13 separate emails.

How do I test email batching in a staging environment?

Use a dedicated Redis instance for staging (never share with production). Write an integration test that fires 10 events in rapid succession and asserts that exactly 1 email is sent. Check both the email provider's logs (Resend, SendGrid, or SES) and your email_log table. The most common failure mode in testing is using a different Redis URL in staging vs production, causing the SETNX to go to the wrong instance.

Does this pattern work with Inngest or other workflow engines?

Inngest and similar tools (Temporal, Step Functions) can replace the digest endpoint entirely. Instead of a self-referencing API call with a sleep, you schedule an Inngest function with a delay. The function runs after the batch window closes, collects events, and sends the digest. This is architecturally cleaner but adds a dependency. For solo founders, the raw SETNX approach has fewer moving parts. Graduate to a workflow engine when you have 5 or more batched notification types.

What is the cost of adding Redis for email batching?

Upstash Redis offers a free tier with 10,000 commands per day, which covers email batching for most early-stage products. At scale, the cost is approximately $0.20 per 100K commands. For comparison, the cost of not batching -- degraded email deliverability, user complaints, and the engineering time to debug spam incidents -- is significantly higher. The 13-duplicate incident consumed 4 hours of debugging time, which at any reasonable engineering rate far exceeds a year of Upstash costs.

Dinesh Challa is an AI Product Manager building production software with Claude Code. Follow him on LinkedIn.

Published April 11, 2026. Part of a series on production engineering patterns for solo founders building AI-powered SaaS products.