Struggling with duplicate welcome emails from your automation script? Understand the core problem of statefulness and learn three practical fixes, from a quick-and-dirty database flag to a robust, event-driven architectural solution.

That “Simple” Welcome Email Automation Is Never Simple, Is It?

I remember it like it was yesterday. It was 3 AM, and the on-call pager was screaming. A “simple” nightly script, designed to regenerate overdue invoices, had gone rogue. A minor bug in its state-tracking logic caused it to run in a tight loop, re-generating and emailing the *same* batch of invoices to a few hundred very important, and now very angry, customers. We spent the next 72 hours doing damage control. This is why when I saw a junior dev on Reddit pulling their hair out over a welcome email script sending duplicates, I felt a familiar pang of dread and empathy. We’ve all been there. Let’s talk about it.

The Real Problem: Your Script Has No Memory

The core issue isn’t your cron job, your query, or your email service. The problem is statefulness. Your script is a goldfish. Every time it runs, it has no memory of what it did five minutes ago. It just executes its instructions: “Find all users created today and send them an email.”

If you run it at 10:00 AM, it emails everyone who signed up since midnight. If you run it again at 10:05 AM (maybe to test something, or because the first run had a network blip), it emails that *exact same list of people again*. The script is doing exactly what you told it to do, but not what you *meant* for it to do. To fix this, we need to give it a memory.

The Fixes: From Duct Tape to a New Engine

There are a few ways to solve this, each with its own trade-offs. I’ll lay out three common patterns we use at TechResolve, from the “get me out of this mess right now” fix to the “let’s build this to last” architecture.

Solution 1: The Quick Fix (aka “The Dirty Flag”)

This is the fastest, simplest, and yes, “dirtiest” way to solve the problem immediately. You add a new column to your `users` table to track the state of the email.

Let’s say you have a `users` table. You’d run a migration to add a boolean flag:

ALTER TABLE users ADD COLUMN welcome_email_sent BOOLEAN DEFAULT FALSE;

Now, your script’s logic changes dramatically. Instead of just selecting users by date, you select users who haven’t received the email yet.

1. SELECT users who need the email:

SELECT id, email FROM users WHERE welcome_email_sent = FALSE;

2. LOOP through these users, send the email.
3. UPDATE the flag for each user *after* the email is successfully sent:

UPDATE users SET welcome_email_sent = TRUE WHERE id = <user_id>;

It’s effective and stops the bleeding immediately. The downside? You’re “polluting” your core user table with operational state. Over time, you might have `password_reset_sent`, `invoice_due_email_sent`, etc. It can get messy, fast.

Pro Tip: When you run the `UPDATE` statement, do it inside the loop right after a successful send. If you wait to do a bulk update at the end and the script fails halfway through, you’ll be right back where you started.

Solution 2: The Permanent Fix (The Event-Driven Architect’s Choice)

This is how we’d build it from scratch today. Instead of a cron job that polls the database, you make the action event-driven. This decouples the “user created” event from the “send email” action.

The Flow:

1. User Signup: Your `auth-service` or application backend successfully creates a new user in the `prod-user-db`.
2. Publish Event: Immediately after the database commit, the service publishes a message to a message queue (like AWS SQS, RabbitMQ, or Google Pub/Sub). The message is simple, containing something like `{ “userId”: 123, “email”: “newuser@example.com” }`.
3. Worker Consumes: You have a separate, long-running service (an “email worker”) whose only job is to listen for messages on that queue.
4. Process & Ack: When the worker picks up a message, it attempts to send the email. If the send is successful, it “acknowledges” the message, which permanently removes it from the queue. If it fails, the message can be automatically retried later.

This is the most robust solution. It’s scalable, resilient to failure, and keeps your services focused on their specific jobs. There’s no polling, no chance of a duplicate run, because once a message is successfully processed, it’s gone for good.

Solution 3: The ‘Nuclear’ Option (The Dedicated Log Table)

This is a solid middle ground. It’s more organized than a dirty flag but less complex to set up than a full-blown message queue. You create a separate table to act as your own, simple, database-backed queue or log.

First, create the table:

CREATE TABLE email_jobs (
    id SERIAL PRIMARY KEY,
    user_id INT NOT NULL,
    job_type VARCHAR(50) DEFAULT 'welcome_email',
    status VARCHAR(20) DEFAULT 'pending', -- pending, sent, failed
    created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
    processed_at TIMESTAMP WITH TIME ZONE
);

The New Flow:

1. User Signup: When a user is created, your application also inserts a row into `email_jobs` for that user.
2. Cron Job Runs: Your cron job’s logic is now to select from this new table:

   SELECT id, user_id FROM email_jobs WHERE status = 'pending' AND job_type = 'welcome_email';

3. Process & Update: It loops through the results, sends the email, and then updates the row’s status to `’sent’` and sets the `processed_at` timestamp.

This approach gives you a fantastic audit trail. You can easily see when a job was created, when it was processed, and if it failed. It’s far cleaner than adding flags to the `users` table and keeps concerns separate.

Comparison at a Glance

So, what’s the right answer? It depends. If you’re a startup and the house is on fire, use the dirty flag to put it out. If you’re building for the long haul or already have the infrastructure, go event-driven. If you’re somewhere in between, the dedicated log table is a pragmatic and professional choice that won’t paint you into a corner.

The key takeaway is to recognize the problem for what it is—a lack of state—and choose a solution that gives your system the memory it needs.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions