1. Introduction — Why Creator Email Platforms Matter

The creator economy has exploded into a $250 billion global market, and at its heart lies one of the oldest yet most powerful digital communication tools: email. ConvertKit, rebranded as Kit in 2024, stands as the definitive example of a creator-first email platform, serving over 500,000 creators across the globe. Unlike traditional email marketing tools built for enterprises and marketing teams, Kit was designed from the ground up for bloggers, podcasters, YouTubers, musicians, and independent authors who need to own their audience without depending on capricious social media algorithms.

At its core, a creator email platform solves a fundamentally different problem than enterprise marketing automation. Enterprise tools like HubSpot, Marketo, or Salesforce Marketing Cloud optimize for complex B2B buyer journeys, multi-touch attribution, and sales team alignment. Creator platforms, by contrast, optimize for simplicity, deliverability, and direct monetization. A creator does not need a 47-field contact record or a lead scoring algorithm powered by gradient boosting. They need to send a beautiful newsletter to 10,000 subscribers, sell a $29 digital course, and understand which of their landing pages converts the best. That is the entire product surface, and it must be executed flawlessly.

Kit's free tier is a masterful growth strategy. Creators with up to 10,000 subscribers can use the platform entirely free, which means the platform effectively subsidizes the acquisition of future paying customers. When a creator's list grows beyond the free tier, or when they want access to advanced features like the Creator Network, paid newsletters, or automated sequences, they convert to a paid plan. This product-led growth model means the platform must be cost-efficient at massive scale, serving hundreds of thousands of accounts that generate zero direct revenue while still maintaining excellent performance and reliability.

The newsletter-first philosophy is equally important. While platforms like Mailchimp evolved from marketing email into newsletter territory, Kit started with newsletters and expanded outward. This means the core write path — composing an email, scheduling it, and delivering it to thousands of subscribers — must be blazingly fast and incredibly reliable. The delivery pipeline is the product. If a creator schedules a newsletter for 8:00 AM Tuesday and it arrives at 8:03 AM, that is a success. If it arrives at 8:45 AM or never arrives at all, the creator loses trust in the platform and may migrate to Substack or Beehiiv.

Creator commerce is the second pillar. Kit built a complete commerce layer that allows creators to sell digital products, offer paid subscriptions, and even accept tips — all without leaving the platform. This eliminates the need for creators to juggle Stripe, Gumroad, Teachable, and a separate email tool. The commerce engine must handle payment processing, subscription management, tax compliance, VAT collection for international sales, license key generation for software products, and instant digital delivery. The revenue these transactions generate is what makes Kit's business model sustainable: they take a percentage of every transaction processed through the platform.

In this comprehensive system design guide, we will dissect every major component of a ConvertKit-like platform. We will cover the data model for managing millions of subscribers across hundreds of thousands of creator accounts, the email delivery pipeline that must process billions of emails per month, the automation engine that executes complex visual workflows, and the commerce subsystem that handles real money with strict compliance requirements. We will estimate capacity, design databases, build APIs, architect distributed systems, and write production-quality C# code. This is a senior-plus engineering guide for building one of the most important infrastructure platforms in the creator economy.

2. Functional & Non-Functional Requirements

Functional Requirements

Before writing a single line of architecture, we must enumerate every feature the platform must support. Creator email platforms have a surprisingly deep feature surface that spans email delivery, subscriber management, marketing automation, commerce, and content publishing. Missing any one of these capabilities creates a gap that drives creators to competing platforms.

Email Broadcasting

Creators must be able to compose emails using a rich text editor that supports plain text and HTML modes. The editor should support merge tags for personalization, such as inserting a subscriber's first name or custom field values. Emails must be schedulable for future delivery, with support for timezone-aware scheduling so a creator in Pacific time can schedule a broadcast for 9:00 AM in each subscriber's local timezone. Broadcasts must support segmentation — sending only to subscribers who have a specific tag, match a set of custom fields, or were added within a certain date range. Draft autosave, preview modes, and send-test-email functionality are essential quality-of-life features.

Visual Automations & Sequences

Creators need a visual automation builder that allows them to construct multi-step email sequences triggered by subscriber actions. A typical workflow might be: when a subscriber joins via a specific form, wait one day, send email A, wait two days, check if they opened email A, if yes send email B with a product pitch, if no send email C with a different subject line. The automation engine must support conditional branching, tagging actions, time delays, link trigger detection, and goal-based short-circuiting. Each automation must maintain per-subscriber state, tracking exactly where each subscriber is within the workflow.

Subscriber Management

The subscriber model must support tags (flat labels like "podcast-listener" or "course-buyer"), segments (dynamic groups defined by filter rules), and custom fields (arbitrary key-value pairs like "company" or "favorite_topic"). Subscribers must be importable via CSV, exportable for compliance (GDPR right to portability), and unsubscribable with a single click. The system must track subscriber lifecycle events: when they joined, which form they used, what emails they opened, what links they clicked, and when they unsubscribed.

Creator Commerce

Creators must be able to list digital products (ebooks, courses, templates, software licenses), configure pricing (one-time or subscription), process payments via Stripe Connect, deliver digital files instantly after purchase, manage subscription renewals and cancellations, handle tax compliance (Sales Tax, VAT, GST), and issue refunds. The commerce layer must also support tip jars — optional one-time payments that fans can make to support a creator.

Landing Pages & Forms

Creators need embeddable opt-in forms and standalone landing pages to capture subscriber email addresses. Forms must support single opt-in and double opt-in workflows, custom branding, thank-you page redirects, and lead magnet delivery. Landing pages must be mobile-responsive, support custom domains, and load quickly for maximum conversion rates.

Non-Functional Requirements

The platform must also support horizontal scaling without downtime, meaning new application instances can be deployed behind load balancers without dropping in-flight requests. Database migrations must be zero-downtime using expand-and-contract patterns. The entire system must be designed for graceful degradation — if the analytics service goes down, email delivery must continue uninterrupted. If the commerce service has a hiccup, subscriber management must remain fully operational.

3. Capacity Estimation & Back-of-Envelope Math

Capacity estimation is the foundation of every good system design. Before we choose databases, design schemas, or architect services, we must understand the scale we are designing for. We will work from the top down: number of creators, number of subscribers, number of emails sent, and storage requirements for commerce and analytics.

Creator & Subscriber Scale

Kit currently serves over 500,000 creators. Let us model for 600,000 creators with a growth trajectory toward 1 million within two years. Not all creators are equal in size. The distribution follows a power law: most creators have small lists (under 1,000 subscribers), while a small percentage have very large lists (100,000+ subscribers).

We must handle up to 3 billion subscriber records. This immediately tells us we need a horizontally sharded database, not a single Postgres instance. Subscriber records are relatively small (approximately 500 bytes each including custom fields), so 3 billion records require approximately 1.5 TB of raw storage — well within the range of a sharded PostgreSQL cluster or a distributed database like CockroachDB.

Email Volume Estimation

Not every creator sends emails to every subscriber every day. The average creator sends approximately 8 broadcasts per month. Some send daily, some send weekly, and some send only when they have something to say. Automations and sequences generate additional email volume — roughly 30% more than broadcast volume alone.

70,000 emails per second at peak is a significant throughput requirement. Each email requires multiple database reads (subscriber record, preferences, merge tags), possible template rendering, tracking pixel injection, and handoff to an SMTP relay or direct delivery infrastructure. The system must be designed with aggressive queuing and parallel processing to handle these bursts.

Storage Requirements

Beyond subscriber records, we need to estimate storage for email content, analytics events, commerce transactions, and digital product files. Email templates and broadcast content are relatively lightweight — text and HTML rarely exceed 50 KB per email. However, analytics events (opens, clicks, unsubscribes) generate significant write volume. Every email sent generates at minimum one open event (if the tracking pixel is loaded) and potentially multiple click events. At 31 billion emails per month with an average 30% open rate, we generate approximately 9.3 billion open events and billions of click events monthly.

Commerce transactions are lower volume but higher value. If 5% of creators sell products with an average of 50 transactions per month, that is 600K × 0.05 × 50 = 1.5 million transactions per month. Each transaction record is approximately 2 KB, so commerce storage is only about 3 GB per month. Digital product files (ebooks, courses) require object storage (S3 or equivalent) and could total 10 TB across all creators.

Bandwidth Estimation

Inbound bandwidth (API traffic from creator dashboards) is modest: approximately 100,000 concurrent creators, each making 5 API calls per minute, with an average response size of 10 KB, gives us approximately 16 MB/s inbound. Outbound bandwidth for email delivery is much larger: 70,000 emails per second at 50 KB average size equals approximately 3.5 GB/s outbound during peak periods. This bandwidth must be distributed across multiple SMTP relay providers to avoid any single provider becoming a bottleneck.

4. Core Data Model Design

The data model is the contract that every service in the system must honor. A well-designed data model makes the right things easy and the wrong things hard. For a creator email platform, the core entities are Creators (accounts), Subscribers, Broadcasts, Sequences, Tags, Forms, Products, and Orders. Let us design each entity with careful attention to relationships, indexing strategy, and partitioning considerations.

Creator (Account)

A Creator represents an account on the platform. Each creator has a unique identity, a plan tier (free, creator, creator pro, team), profile information, and billing details. Creators own all the content and subscriber data within their account. The creator entity must support team collaboration with role-based access control (owner, editor, viewer). Each creator has a unique subdomain for their public-facing landing pages and a default sender email address.

Subscriber

Subscribers are the most numerous entity in the system, and their data model must be designed for extreme scale. A subscriber belongs to exactly one creator (no cross-creator subscriber sharing in the base model). Subscribers have a state machine: pending (double opt-in awaiting confirmation), active (confirmed and receiving emails), unsubscribed (opted out), and bounced (hard-bounced and automatically suppressed). Each subscriber can have multiple tags, custom fields, and a full event history of every interaction with the creator's emails.

Broadcast

A broadcast is a one-time email sent to a segment of a creator's subscribers. Broadcasts have a lifecycle: draft, scheduled, sending, sent, and cancelled. Each broadcast stores its content (subject line, body HTML, plain text version), targeting criteria (which segments or tags to include/exclude), scheduling metadata (send time, timezone mode), and aggregate metrics (total sent, opens, clicks, bounces, unsubscribes).

Sequence & Automation

A sequence is a multi-step email workflow with branching logic. The sequence definition is a directed acyclic graph (DAG) where nodes are steps (email, delay, condition, tag) and edges are transitions. Each subscriber in a sequence has an execution state that tracks their current step, the timestamp of their last action, and any pending timers. The sequence definition must be versioned so that changes to the workflow do not disrupt subscribers who are already mid-sequence.

Tags, Segments, and Custom Fields

Tags are flat string labels applied to subscribers. They are the primary mechanism creators use to organize their audience. A subscriber can have zero or more tags, and tags are applied either manually by the creator, automatically by automation rules, or through import mapping. Segments are saved filter definitions that dynamically compute a set of matching subscribers based on rules like "has tag X AND custom field Y greater than 100 AND joined after date Z." Segments are not stored as materialized sets — they are computed on demand or cached with periodic refresh. Custom fields are arbitrary key-value pairs attached to subscribers, supporting string, number, date, and boolean types.

Forms & Landing Pages

Forms are the entry points through which new subscribers join a creator's list. A form can be embedded on a website, hosted as a landing page, or triggered by a third-party integration. Forms store their design configuration, incentive settings (lead magnet file to deliver on signup), and conversion tracking metadata. Each form maintains its own subscriber count and conversion rate for analytics purposes.

Products & Orders

Products represent digital goods or subscriptions that a creator sells. Products have a name, description, pricing configuration (one-time, recurring, or pay-what-you-want), digital file attachments, and a checkout page. Orders record individual transactions: which subscriber purchased which product, the amount paid, payment status (pending, completed, refunded, failed), Stripe payment intent ID, and fulfillment status (delivered, undelivered). The commerce model must be audit-ready for tax compliance and accounting.

The partitioning strategy is clear: most queries are scoped to a single creator, so partitioning by creator_id keeps related data co-located and enables efficient range scans within an account. Subscriber event history is the exception — it is partitioned by subscriber_id to support analytics queries that traverse a single subscriber's full interaction history across the platform.

5. API Design — RESTful Endpoints

The API layer is the contract between the creator-facing dashboard, third-party integrations, and the internal services. A well-designed API for a creator email platform must be RESTful, versioned, paginated, and rate-limited. The API surface spans four major domains: subscriber management, email operations, sequence management, and commerce. Each domain uses consistent conventions for request/response formatting, error handling, and authentication via API keys scoped to individual creator accounts.

Subscriber Management API

HTTP
POST   /v3/subscribers
GET    /v3/subscribers/{id}
PATCH  /v3/subscribers/{id}
DELETE /v3/subscribers/{id}
GET    /v3/subscribers?tag=podcast&state=active&page=1&per_page=100
POST   /v3/subscribers/{id}/tags
DELETE /v3/subscribers/{id}/tags/{tag_name}
POST   /v3/subscribers/import
GET    /v3/subscribers/export?format=csv&tag=customer

The subscriber creation endpoint accepts an email address and optional metadata (name, tags, custom fields). If the subscriber already exists for this creator, it returns the existing record with a 200 status rather than creating a duplicate. The bulk import endpoint accepts a CSV file or JSON array and returns a job ID for async processing. The export endpoint streams a CSV download for GDPR compliance. All list endpoints support cursor-based pagination for efficient traversal of large subscriber bases.

Broadcast API

HTTP
POST   /v3/broadcasts
GET    /v3/broadcasts/{id}
PATCH  /v3/broadcasts/{id}
DELETE /v3/broadcasts/{id}
POST   /v3/broadcasts/{id}/schedule
POST   /v3/broadcasts/{id}/send-now
POST   /v3/broadcasts/{id}/cancel
GET    /v3/broadcasts/{id}/stats

Broadcasts follow a two-phase pattern: first create the broadcast as a draft with content and targeting criteria, then schedule or send it. The schedule endpoint accepts a timestamp and timezone mode. The stats endpoint returns real-time delivery metrics as the broadcast progresses from sending to sent. Content is provided as a JSON object with subject, html_body, plain_text_body, and optional template_id fields.

Sequence API

HTTP
POST   /v3/sequences
GET    /v3/sequences/{id}
PATCH  /v3/sequences/{id}
POST   /v3/sequences/{id}/activate
POST   /v3/sequences/{id}/deactivate
GET    /v3/sequences/{id}/executions
GET    /v3/sequences/{id}/stats

Sequence definitions are submitted as a complete DAG in a single POST request. The DAG is validated on the server side to ensure there are no cycles, all referenced steps exist, and delay values are within acceptable bounds. Activation transitions the sequence from draft to live, at which point new subscribers entering the trigger criteria begin executing the workflow. Deactivation pauses the sequence without cancelling in-progress subscribers — they resume when the sequence is reactivated.

Commerce API

HTTP
POST   /v3/products
GET    /v3/products/{id}
PATCH  /v3/products/{id}
GET    /v3/products/{id}/orders
POST   /v3/products/{id}/checkout
GET    /v3/orders/{id}
POST   /v3/orders/{id}/refund
GET    /v3/earnings?period=monthly

The commerce API wraps Stripe Connect under the hood. Product creation configures a Stripe product and price in a single operation. The checkout endpoint generates a hosted checkout URL that the creator can link to from their landing page. The earnings endpoint aggregates revenue across all products for the creator's dashboard. Refunds are processed synchronously through the Stripe API and recorded in the local database for accounting purposes.

Rate Limiting & Authentication

Authentication uses API keys with a Bearer token scheme. Keys are scoped to a single creator account and carry the creator's permission level. The API gateway validates keys, enforces rate limits, and routes requests to the appropriate service. All API responses include X-RateLimit-Remaining and Retry-After headers to support client-side backoff logic. Error responses follow a consistent format with a machine-readable error code, a human-readable message, and an optional details field for validation errors.

6. High-Level System Architecture

The architecture of a creator email platform must handle asymmetric workloads: light read traffic from creator dashboards coexisting with massive write-intensive email delivery pipelines. The system is composed of six primary subsystems: the Creator Dashboard (web application), the API Gateway, the Core Services (subscriber, broadcast, sequence, commerce), the Email Delivery Pipeline, the Analytics Pipeline, and the Infrastructure Layer (databases, caches, queues, object storage).

Service Responsibilities

Subscriber Service manages all subscriber CRUD operations, tag management, segment computation, and custom field operations. It is the most frequently called service and must handle the highest read throughput. It reads primarily from PostgreSQL with a heavy Redis caching layer for hot subscriber records. Write operations fan out to the event stream for analytics processing.

Broadcast Service handles the creation, scheduling, and lifecycle management of one-time email broadcasts. When a broadcast is scheduled, it computes the target subscriber list, generates per-subscriber personalized content, and enqueues email delivery jobs into the broadcast queue. The broadcast service does not send emails directly — it delegates that responsibility to the email workers.

Sequence Engine is the most complex service. It maintains the DAG definition for each sequence, tracks per-subscriber execution state, evaluates conditional branches, manages delay timers, and triggers email sends at the appropriate moments. The sequence engine must handle millions of concurrent subscriber executions, each at different stages of their respective workflows. It uses Kafka for durable event processing and Redis for fast state lookups.

Commerce Service manages products, checkout flows, payment processing via Stripe Connect, subscription lifecycle, and refund handling. It communicates with Stripe's API for payment operations and maintains a local ledger for accounting and analytics. The commerce service must be strongly consistent for financial operations — no double charges, no lost payments, no phantom refunds.

Email Workers are the workhorses of the delivery pipeline. They consume jobs from the broadcast and trigger queues, render personalized email content, inject tracking pixels and unsubscribe links, and hand off emails to the SMTP relay pool. Workers are stateless and horizontally scalable — we can run 500 or 5,000 instances depending on load. Each worker maintains connections to multiple SMTP relays and implements retry logic with exponential backoff for transient failures.

Tracking Service processes open and click events in real time. When a subscriber opens an email (tracking pixel loaded) or clicks a link (redirected through our tracking URL), the tracking service records the event, updates the subscriber's engagement profile, and evaluates whether the event triggers any automation rules (for example, adding a tag when a subscriber clicks a product link). The tracking service must be extremely high-throughput — it processes billions of events per month — but can tolerate eventual consistency since real-time precision is not critical for email analytics.

This architecture separates concerns cleanly: the creator-facing services handle CRUD and business logic, the delivery pipeline handles the heavy lifting of email sending, and the analytics pipeline handles event processing and reporting. Each subsystem can scale independently, and failures in one subsystem do not cascade to others. The message queues provide natural backpressure — if email workers are overwhelmed, jobs queue up rather than being lost.

7. Newsletter & Broadcast System

The newsletter and broadcast system is the beating heart of any creator email platform. This is the feature that creators use most frequently, and it must deliver a flawless experience from composition through delivery. The system must support a rich text editor, HTML template rendering, timezone-aware scheduling, segment-based targeting, personalization through merge tags, and real-time delivery tracking.

Editor & Content Pipeline

Creators compose emails through a block-based rich text editor that supports paragraphs, headings, images, buttons, dividers, and custom HTML blocks. The editor operates in two modes: visual (WYSIWYG) and code (raw HTML). Content is stored as a JSON document that describes the block structure, which allows the system to render the same content into multiple output formats: HTML email for rich email clients, plain text for text-only clients, and a web version for the hosted archive.

When a broadcast is scheduled or sent immediately, the content pipeline performs several transformations. First, it resolves merge tags — replacing placeholders like {{ subscriber.first_name }} with actual subscriber data. Second, it inlines CSS styles, since many email clients strip <style> blocks. Third, it injects a tracking pixel (a 1x1 transparent image) at the end of the email body. Fourth, it replaces all links with tracked redirect URLs that pass through our click tracking service before redirecting to the original destination. Fifth, it appends a standardized footer with the creator's mailing address and an unsubscribe link, as required by CAN-SPAM.

Scheduling Engine

The scheduling engine must support two modes: immediate send and scheduled send. Immediate sends enqueue jobs right away. Scheduled sends must account for subscriber timezone preferences. When a creator in New York schedules a broadcast for "9:00 AM local time," the system must send the email at 9:00 AM Eastern for Eastern subscribers, 9:00 AM Central for Central subscribers, and so on. This means a single scheduled broadcast fans out into multiple time-bucketed job groups, each enqueued at the appropriate time.

C#
public class BroadcastScheduler
{
    private readonly IJobQueue _jobQueue;
    private readonly ISubscriberRepository _subscriberRepo;

    public async Task ScheduleBroadcast(Broadcast broadcast, DateTime targetTime, TimezoneMode mode)
    {
        if (mode == TimezoneMode.SendImmediately)
        {
            var subscribers = await _subscriberRepo
                .GetTargetSubscribersAsync(broadcast.CreatorId, broadcast.SegmentCriteria);
            var jobs = subscribers.Select(s => new EmailJob
            {
                BroadcastId = broadcast.Id,
                SubscriberId = s.Id,
                ScheduledAt = DateTime.UtcNow
            });
            await _jobQueue.EnqueueBatchAsync(jobs);
            return;
        }

        var timezoneGroups = new Dictionary<string, List<Subscriber>>();
        foreach (var subscriber in await _subscriberRepo
            .GetTargetSubscribersAsync(broadcast.CreatorId, broadcast.SegmentCriteria))
        {
            var tz = subscriber.Timezone ?? "UTC";
            if (!timezoneGroups.ContainsKey(tz))
                timezoneGroups[tz] = new List<Subscriber>();
            timezoneGroups[tz].Add(subscriber);
        }

        foreach (var (tz, subs) in timezoneGroups)
        {
            var localSendTime = TimeZoneInfo
                .FindSystemTimeZoneById(tz)
                .ConvertTimeToUtc(targetTime.Date
                    .Add(targetTime.TimeOfDay));
            var jobs = subs.Select(s => new EmailJob
            {
                BroadcastId = broadcast.Id,
                SubscriberId = s.Id,
                ScheduledAt = localSendTime
            });
            await _jobQueue.EnqueueBatchAsync(jobs);
        }
    }
}

Template Rendering

Template rendering must be fast and safe. We use a sandboxed Razor template engine that allows merge tags and conditional blocks but prevents arbitrary code execution. Templates are compiled into IL code on first use and cached in memory for subsequent renders. A single broadcast to 1 million subscribers requires 1 million template renders — at 1 millisecond per render, this is 1,000 seconds (approximately 17 minutes) on a single core. With 100 worker threads across 10 machines, the total render time drops to under 2 minutes.

Deliverability Controls

Every broadcast passes through a pre-send quality check that evaluates sender reputation, domain authentication status (SPF, DKIM, DMARC), content spam score (using a library like SpamAssassin), and link reputation (checking against known phishing databases). If any check fails, the broadcast is flagged for manual review rather than being sent automatically. This prevents creators from accidentally damaging their sender reputation and getting their emails land in spam folders.

8. Visual Automations & Sequences

Visual automations are what elevate a creator email platform from a simple broadcast tool to a sophisticated marketing engine. The sequence builder allows creators to construct complex, multi-step workflows using a visual drag-and-drop interface. Each workflow is represented internally as a directed acyclic graph (DAG), where nodes represent actions or conditions and edges represent the flow of subscribers through the workflow.

Node Types

The automation engine supports several node types, each with distinct behavior. Email nodes send a specific email to the subscriber. Delay nodes pause the subscriber's execution for a specified duration (hours, days, or until a specific date). Condition nodes evaluate a boolean expression and route the subscriber down one of two branches (yes/no). Tag nodes add or remove tags from the subscriber. Goal nodes define a target event (such as making a purchase) and automatically advance subscribers to that node if the event occurs, regardless of their current position in the workflow. Link trigger nodes wait for the subscriber to click a specific link in a previous email.

Execution Engine

The sequence execution engine is a distributed state machine. Each subscriber-in-sequence has an execution record that tracks: the sequence ID, the current step ID, the status (running, paused, completed, exited), the timestamp of the last step execution, and any pending timer expiration. When a subscriber enters a sequence, the engine creates an execution record and begins evaluating the DAG from the root node.

For email nodes, the engine enqueues an email job and advances the subscriber to the next node once the email is sent. For delay nodes, the engine schedules a timer and suspends the subscriber's execution until the timer fires. For condition nodes, the engine evaluates the condition expression against the subscriber's current data (tags, custom fields, email engagement history) and routes the subscriber down the appropriate branch. The engine re-evaluates conditions for goal nodes whenever a relevant event occurs — if a subscriber makes a purchase while they are in a delay step three nodes before the goal, the engine short-circuits their execution directly to the goal node.

Concurrency & State Management

The biggest challenge in the execution engine is managing millions of concurrent subscriber executions without overwhelming the database. The solution is a three-tier state management approach. First, the execution state is stored in PostgreSQL as the source of truth. Second, active executions are cached in Redis with a 5-minute TTL, allowing the engine to read state from memory rather than the database for hot subscribers. Third, pending timers are stored in a dedicated timer queue backed by a sorted set in Redis, with a background poller that fires expired timers and enqueues corresponding jobs.

C#
public class SequenceExecutionEngine
{
    private readonly IExecutionRepository _executionRepo;
    private readonly ISequenceDefinitionRepository _sequenceRepo;
    private readonly ITimerQueue _timerQueue;
    private readonly IEmailJobQueue _emailQueue;
    private readonly ISubscriberService _subscriberService;

    public async Task AdvanceSubscriber(Guid sequenceId, Guid subscriberId)
    {
        var execution = await _executionRepo.GetAsync(sequenceId, subscriberId)
            ?? throw new InvalidOperationException("No active execution found");

        var sequence = await _sequenceRepo.GetAsync(sequenceId);
        var currentNode = sequence.GetNode(execution.CurrentStepId);

        switch (currentNode.Type)
        {
            case StepType.Email:
                var subscriber = await _subscriberService.GetAsync(subscriberId);
                var content = await RenderEmailAsync(currentNode.EmailTemplateId, subscriber);
                await _emailQueue.EnqueueAsync(new EmailJob
                {
                    SubscriberId = subscriberId,
                    Content = content,
                    SequenceExecutionId = execution.Id
                });
                execution.CurrentStepId = currentNode.NextStepId;
                break;

            case StepType.Delay:
                var fireAt = DateTime.UtcNow.Add(currentNode.DelayDuration);
                await _timerQueue.ScheduleAsync(execution.Id, fireAt);
                execution.Status = ExecutionStatus.Waiting;
                break;

            case StepType.Condition:
                var sub = await _subscriberService.GetAsync(subscriberId);
                var result = await EvaluateConditionAsync(currentNode.Condition, sub);
                execution.CurrentStepId = result
                    ? currentNode.YesBranchStepId
                    : currentNode.NoBranchStepId;
                break;

            case StepType.Tag:
                await _subscriberService.AddTagAsync(subscriberId, currentNode.TagName);
                execution.CurrentStepId = currentNode.NextStepId;
                break;

            case StepType.Goal:
                execution.Status = ExecutionStatus.Waiting;
                break;
        }

        await _executionRepo.SaveAsync(execution);

        if (execution.Status == ExecutionStatus.Running)
            await AdvanceSubscriber(sequenceId, subscriberId);
    }
}

Versioning & Migration

When a creator modifies a live sequence, existing subscribers should not be disrupted. The system implements sequence versioning: each activation creates an immutable snapshot of the DAG definition. Subscribers who entered under version 1 continue executing version 1 until they complete or exit. New subscribers enter under the latest version. This prevents the nightmare scenario where a creator rearranges their automation and thousands of subscribers suddenly receive the wrong emails or get stuck in broken workflows.

Automation Analytics

Each sequence node maintains per-step metrics: how many subscribers entered, how many completed, how many exited (unsubscribed or bounced), conversion rate at each decision point, and average time spent at each step. These metrics help creators optimize their automations by identifying bottlenecks (where subscribers stall or drop off) and high-performing branches (where engagement is strongest). The analytics are computed from the event stream and stored in a materialized view that refreshes every 5 minutes.

9. Subscriber Management at Scale

Subscriber management is the core of the platform, and it must handle the complexity of millions of subscribers per creator with elegance and performance. The key design decisions revolve around three concepts: tags, segments, and custom fields. Each serves a distinct purpose, and misunderstanding the differences between them is one of the most common mistakes in email platform design.

Tags vs. Segments vs. Custom Fields

Tags are flat string labels applied to subscribers. They are binary — a subscriber either has a tag or does not. Tags are the simplest organizational tool and are used for: source tracking (which form or landing page did the subscriber come from), interest classification (podcast listener, course buyer), lifecycle stage (new, engaged, at-risk, churned), and manual grouping. Tags are stored in a many-to-many relationship with subscribers and are indexed for fast lookup.

Segments are dynamic, rule-based groups. A segment is defined by a set of filter conditions that are evaluated against subscriber attributes in real time. For example, a segment might be defined as "subscribers who have the tag 'customer' AND whose custom field 'purchase_total' is greater than 100 AND who were added after January 1, 2025." Segments are not stored as materialized sets of subscribers — they are filter definitions that are evaluated at query time or cached with periodic refresh for performance.

Custom fields are arbitrary key-value pairs attached to subscribers. They support string, number, date, and boolean types. Common custom fields include first_name, last_name, company, city, and any creator-specific data they want to track. Custom fields are stored in a JSONB column for flexibility and indexed using GIN indexes for fast queries on specific field values.

Subscriber State Machine

Every subscriber follows a lifecycle with well-defined states and transitions. Understanding this state machine is critical for ensuring that subscribers receive the right emails at the right time and that the platform complies with anti-spam regulations.

When a new subscriber signs up with double opt-in enabled, they enter the Pending state. A confirmation email is sent with a unique verification link. If they click the link within 48 hours, they transition to Active. If they do not confirm, they remain in Pending and are automatically purged after 30 days. Subscribers who hard-bounce (invalid email address) or file spam complaints are moved to Bounced or Complaint states and are permanently suppressed — they will never receive another email from any creator on the platform. This global suppression list is shared across all creator accounts to prevent blacklist circumvention.

Bulk Operations

Creators frequently need to perform bulk operations: importing thousands of subscribers from a CSV, adding a tag to all subscribers matching a criteria, or exporting their entire list. These operations must be performed asynchronously to avoid blocking the API. When a creator initiates a bulk import, the system accepts the file, validates email addresses, checks against the global suppression list, and enqueues individual subscriber creation jobs. The creator can monitor progress through a job status endpoint that returns the percentage complete, records processed, and any errors encountered.

C#
public class SubscriberManager
{
    private readonly ISubscriberRepository _subscriberRepo;
    private readonly ITagRepository _tagRepo;
    private readonly ISuppressionList _suppressionList;
    private readonly IEventPublisher _eventPublisher;

    public async Task<ImportResult> ImportSubscribersAsync(
        Guid creatorId, IEnumerable<SubscriberImportRecord> records)
    {
        var result = new ImportResult();
        var batch = new List<Subscriber>();

        foreach (var record in records)
        {
            result.TotalRecords++;

            if (!IsValidEmail(record.Email))
            {
                result.Errors.Add($"{record.Email}: Invalid email format");
                result.ErrorCount++;
                continue;
            }

            if (await _suppressionList.ContainsAsync(record.Email))
            {
                result.SuppressedCount++;
                continue;
            }

            var existing = await _subscriberRepo
                .FindByEmailAsync(creatorId, record.Email);
            if (existing != null)
            {
                result.DuplicateCount++;
                continue;
            }

            var subscriber = new Subscriber
            {
                Id = Guid.NewGuid(),
                CreatorId = creatorId,
                Email = record.Email,
                FirstName = record.FirstName,
                LastName = record.LastName,
                State = SubscriberState.Active,
                CreatedAt = DateTime.UtcNow
            };

            batch.Add(subscriber);

            if (record.Tags?.Any() == true)
            {
                foreach (var tagName in record.Tags)
                {
                    var tag = await _tagRepo.GetOrCreateAsync(creatorId, tagName);
                    await _tagRepo.AddSubscriberTagAsync(subscriber.Id, tag.Id);
                }
            }

            result.ImportedCount++;

            if (batch.Count >= 1000)
            {
                await _subscriberRepo.BulkInsertAsync(batch);
                batch.Clear();
            }
        }

        if (batch.Any())
            await _subscriberRepo.BulkInsertAsync(batch);

        await _eventPublisher.PublishAsync(new SubscribersImportedEvent
        {
            CreatorId = creatorId,
            Result = result
        });

        return result;
    }
}

Subscriber Scoring

Subscriber engagement scoring helps creators identify their most engaged (and most at-risk) subscribers. The scoring model assigns points for positive actions (opening an email: +1, clicking a link: +3, making a purchase: +10) and deducts points for inactivity (no opens in 30 days: -5, no opens in 90 days: -15). Scores are computed daily in a batch job and stored as a custom field. Creators can then segment their audience by engagement score to send re-engagement campaigns to at-risk subscribers or VIP offers to their most engaged fans.

The scoring system is designed to be transparent — creators can see exactly why a subscriber has a particular score, which actions contributed positively, and what they can do to re-engage at-risk subscribers. This transparency builds trust in the platform and helps creators make data-driven decisions about their email strategy.

10. Creator Commerce — Digital Products & Payments

Creator commerce transforms a creator email platform from a cost center (email is an expense) into a revenue engine (email drives sales). The commerce subsystem allows creators to sell digital products, offer paid subscriptions, and process payments without leaving the platform. This is a significant competitive advantage over platforms like Mailchimp, which require creators to integrate with external tools like Gumroad, Teachable, or Shopify for commerce functionality.

Product Types

The platform supports four primary product types. Digital downloads are one-time purchases of files — ebooks, PDFs, templates, code snippets, or any digital asset. After payment, the buyer receives an email with a secure download link that expires after 72 hours and a limited number of uses. Online courses are structured educational content delivered as a sequence of lessons. Courses can include text, images, video embeds, and downloadable resources. Membership subscriptions provide ongoing access to content (members-only posts, community access, exclusive newsletter) billed monthly or annually. Tip jars allow fans to make voluntary one-time payments to support a creator, with optional preset amounts and custom amounts.

Payment Processing with Stripe Connect

The platform uses Stripe Connect to handle payments. Stripe Connect allows the platform to act as a marketplace: creators connect their Stripe accounts, payments flow from buyers to creators, and the platform takes a transaction fee. This model is preferable to the platform collecting payments and paying out creators because it reduces the platform's regulatory burden (the platform is not holding creator funds) and gives creators direct access to their Stripe dashboard for financial transparency.

Subscription Management

Subscriptions are the most complex commerce feature because they involve recurring billing, grace periods, dunning (failed payment recovery), and lifecycle management. When a subscriber's recurring payment fails (expired card, insufficient funds), Stripe automatically retries the payment according to a configurable schedule. During the retry period, the subscriber retains access. If all retries fail, the subscription is marked as past due, and the subscriber receives a notification email asking them to update their payment method. After a configurable grace period (typically 7 days), the subscription is cancelled, and access is revoked.

C#
public class CommerceService
{
    private readonly IStripeClient _stripe;
    private readonly IOrderRepository _orderRepo;
    private readonly IProductRepository _productRepo;
    private readonly IEmailService _emailService;

    public async Task<CheckoutResult> CreateCheckoutAsync(
        Guid productId, Guid subscriberId, string successUrl, string cancelUrl)
    {
        var product = await _productRepo.GetAsync(productId)
            ?? throw new NotFoundException("Product not found");

        var session = await _stripe.Checkout.Sessions.CreateAsync(new SessionCreateOptions
        {
            PaymentMethodTypes = new List<string> { "card" },
            LineItems = new List<SessionLineItemOptions>
            {
                new SessionLineItemOptions
                {
                    Price = product.StripePriceId,
                    Quantity = 1
                }
            },
            Mode = product.IsRecurring ? "subscription" : "payment",
            SuccessUrl = successUrl + "?session_id={CHECKOUT_SESSION_ID}",
            CancelUrl = cancelUrl,
            Metadata = new Dictionary<string, string>
            {
                { "product_id", productId.ToString() },
                { "subscriber_id", subscriberId.ToString() },
                { "creator_id", product.CreatorId.ToString() }
            }
        });

        return new CheckoutResult
        {
            SessionId = session.Id,
            Url = session.Url
        };
    }

    public async Task HandlePaymentSucceeded(string stripeSessionId)
    {
        var session = await _stripe.Checkout.Sessions.GetAsync(stripeSessionId);
        var productId = Guid.Parse(session.Metadata["product_id"]);
        var subscriberId = Guid.Parse(session.Metadata["subscriber_id"]);
        var product = await _productRepo.GetAsync(productId);

        var order = new Order
        {
            Id = Guid.NewGuid(),
            ProductId = productId,
            SubscriberId = subscriberId,
            CreatorId = product.CreatorId,
            Amount = session.AmountTotal ?? 0,
            Currency = session.Currency,
            StripePaymentIntentId = session.PaymentIntentId,
            StripeSubscriptionId = session.SubscriptionId,
            Status = OrderStatus.Completed,
            CreatedAt = DateTime.UtcNow
        };

        await _orderRepo.CreateAsync(order);
        await _emailService.SendProductDeliveryEmailAsync(order, product);
    }
}

Tax Compliance

Digital product sales are subject to sales tax, VAT, and GST depending on the buyer's location and the creator's tax jurisdiction. The platform integrates with Stripe Tax to automatically calculate, collect, and remit the correct tax amount for each transaction. Stripe Tax maintains a global tax rule database that is updated continuously as tax laws change. The platform also generates tax reports for creators, including annual sales summaries and 1099-K forms for US creators who exceed the IRS reporting threshold.

11. Landing Pages & Forms

Landing pages and forms are the growth engine of every creator's email list. A creator can have the best newsletter in the world, but without effective sign-up mechanisms, no one will read it. The platform must provide creators with easy-to-use, high-converting tools for capturing subscriber email addresses, delivering lead magnets, and building branded landing pages that look professional without requiring any design skills.

Form Types

The platform supports five form types. Inline forms are embedded directly within a creator's existing website content — typically placed within blog posts or in the sidebar. Modal forms appear as overlay dialogs triggered by user behavior (time on page, scroll depth, exit intent). Slide-in forms slide in from the bottom or side of the viewport after a configurable delay. Sticky bar forms are persistent bars fixed to the top or bottom of the page. Full-page forms (landing pages) are standalone pages hosted by the platform, complete with custom domain support, SEO meta tags, and Open Graph tags for social sharing.

Form Builder

The form builder is a WYSIWYG editor that allows creators to customize every aspect of their forms: colors, fonts, spacing, form fields, submit button text, incentive message, and success state. Creators can preview their forms on desktop and mobile before publishing. Forms are rendered as embeddable JavaScript snippets that creators paste into their website HTML. The JavaScript snippet loads the form configuration from the platform's API and renders it in an iframe to avoid CSS conflicts with the creator's website.

Lead Magnet Delivery

Many creators offer a free resource (lead magnet) in exchange for an email address. Common lead magnets include PDF guides, checklist templates, video mini-courses, and discount codes. When a subscriber signs up through a form with a lead magnet, the platform automatically sends a delivery email with a secure download link. The download link is time-limited (72 hours), usage-limited (3 downloads), and protected against sharing by requiring the subscriber's email address for authentication.

Conversion Tracking

Every form tracks impressions (how many times it was viewed) and conversions (how many times it was submitted), allowing creators to calculate conversion rates. The platform also tracks the subscriber source — which form or landing page each subscriber came from — enabling creators to compare the effectiveness of different lead magnets and opt-in placements. Conversion data is stored in the analytics pipeline and visualized in the creator's dashboard with trend graphs, comparison tables, and funnel visualizations.

Custom Domains

Pro and Team plan creators can map custom domains to their landing pages (for example, join.creatorsname.com instead of creatorsname.Kit.com). The platform manages SSL certificate provisioning via Let's Encrypt, DNS verification, and automatic certificate renewal. Custom domains are configured through the dashboard with a step-by-step wizard that verifies DNS records before activating the domain.

12. Creator Network & Cross-Promotion

The Creator Network is one of Kit's most innovative features and a significant competitive moat. It allows creators to recommend other creators to their subscribers, building a network effect that benefits all participants. When Creator A recommends Creator B, subscribers of Creator A who opt in to the recommendation are added to Creator B's list. This creates a virtuous cycle: the more creators participate, the more subscribers flow through the network, and the more valuable participation becomes for every creator.

Recommendation Algorithm

The recommendation engine suggests relevant creators based on several signals: topic similarity (comparing the content tags and categories of creators), audience overlap (creators whose subscribers share similar interests), subscriber growth rate (creators who are growing quickly tend to produce engaging content), and engagement quality (creators whose emails have high open and click rates). The algorithm balances relevance with diversity — it avoids recommending creators who are direct competitors to each other, instead focusing on complementary creators whose audiences would benefit from cross-discovery.

Cross-Promotion Mechanics

When a creator enables cross-promotion, their emails include a "Recommended for you" section at the bottom that showcases one or two recommended creators. The recommendation is personalized — different subscribers see different recommendations based on their interests and engagement history. When a subscriber clicks a recommendation, they are taken to the recommended creator's profile page, which showcases the creator's best content and includes an opt-in form. If the subscriber opts in, they are added to the recommended creator's subscriber list with the source tag "network_recommendation."

The network tracks the effectiveness of every recommendation: how many impressions it received, how many clicks it generated, how many opt-ins resulted, and the engagement quality of the subscribers acquired through the network. Creators can see a network dashboard that shows their recommendation performance, the performance of their recommendations of others, and the net subscriber flow (subscribers gained through recommendations minus subscribers lost to other creators' recommendations).

Fraud Prevention

The network must be protected against gaming. Creators cannot recommend themselves through multiple accounts, cannot offer incentives for subscribers to opt in to recommendations (this would be list buying), and cannot mass-recommend unrelated creators to farm subscribers. The platform enforces quality standards: creators with consistently low engagement rates, high unsubscribe rates, or spam complaints are automatically excluded from the network. The recommendation algorithm also detects suspicious patterns, such as rapid mutual recommendation exchanges between the same set of creators.

Network Effects & Growth

The Creator Network creates a powerful flywheel effect. More creators join the network because it provides free subscriber growth. More subscribers flow through the network because the recommendations are relevant and high-quality. The network becomes more valuable as it grows because the algorithm has more creators to match and can provide better recommendations. This network effect is a significant barrier to competition — a new entrant must not only build the technical platform but also recruit enough creators to make the network valuable from day one.

13. Tip Jar & Paid Newsletters

Tip jars and paid newsletters represent the monetization layer that transforms email from a marketing channel into a direct revenue stream for creators. These features allow fans to financially support creators through one-time tips or recurring paid subscriptions, creating a sustainable income model for independent content creators who may not have traditional advertising or sponsorship revenue.

Tip Jar Implementation

The tip jar is a simple but powerful feature. Creators enable a "Support me" button on their newsletter archive page and within their emails. Fans can click the button and choose a preset amount ($3, $5, $10, $25) or enter a custom amount. Payment is processed through Stripe using a simplified checkout flow that remembers the fan's payment method for future tips. After tipping, the fan receives a thank-you email from the creator, and the creator receives a notification of the tip with the fan's name (if provided) and an optional message.

The tip jar feature must handle several edge cases. Tips are non-refundable by default (they are voluntary contributions, not purchases), but the platform provides a grace period where accidental tips can be cancelled. The platform charges a transaction fee (typically 5-8%) on tips, which is higher than the fee on product sales because tips have no fulfillment obligation. Creators can see their tip history, including a leaderboard of their most generous supporters, and can send special thank-you emails to tipsters.

Paid Newsletter Subscriptions

Paid newsletters allow creators to gate their content behind a subscription wall. Creators configure which emails are free (typically welcome emails and promotional content) and which are paid (typically in-depth analysis, exclusive content, or early access). Subscribers who have not paid for a subscription receive a truncated preview of paid emails with a call-to-action to upgrade. The subscription can be configured as monthly or annual, with optional introductory pricing and free trial periods.

Content Metering

The metering engine tracks how many free emails each subscriber has received and enforces the content gate. When a paid email is sent, the system first checks whether each subscriber in the target segment has an active paid subscription. Subscribers with active subscriptions receive the full email. Subscribers without paid access receive a teaser version — the first 200 words of the email body with a prominent upgrade CTA. The metering state is stored per-subscriber per-creator and is updated in real time as emails are sent.

C#
public class PaidNewsletterService
{
    private readonly ISubscriptionRepository _subscriptionRepo;
    private readonly IContentGateRepository _contentGateRepo;

    public async Task<EmailContent> GetPersonalizedContent(
        Guid broadcastId, Guid subscriberId)
    {
        var broadcast = await _broadcastRepo.GetAsync(broadcastId);
        var subscription = await _subscriptionRepo
            .GetActiveAsync(broadcast.CreatorId, subscriberId);

        if (broadcast.ContentGate == ContentGateType.Free || subscription != null)
        {
            return broadcast.FullContent;
        }

        var freeWords = ExtractFirstNWords(broadcast.FullContent.Body, 200);
        return new EmailContent
        {
            Subject = broadcast.FullContent.Subject,
            Body = freeWords + RenderUpgradeCTA(broadcast.CreatorId),
            IsTeaser = true
        };
    }

    private string RenderUpgradeCTA(Guid creatorId)
    {
        return $@"
            <div style='text-align:center; padding:30px; background:#f9fafb;
                 border-top:2px solid #e5e7eb; margin-top:20px;'>
                <h3 style='margin-bottom:10px;'>This is a premium newsletter</h3>
                <p>Subscribe to get the full article and exclusive content.</p>
                <a href='https://platform.com/{creatorId}/subscribe'
                   style='display:inline-block;padding:12px 30px;
                   background:#2563eb;color:#fff;border-radius:8px;
                   text-decoration:none;font-weight:bold;'>
                   Subscribe Now — $9/month
                </a>
            </div>";
    }
}

Revenue Dashboard

Creators with paid newsletters and tips see a unified revenue dashboard that aggregates all income streams: product sales, subscription revenue, and tips. The dashboard shows daily, weekly, and monthly revenue trends, churn rate for paid subscriptions, average revenue per subscriber (ARPS), and projected monthly recurring revenue (MRR). Revenue data is pulled from the commerce service and refreshed every 15 minutes. Creators can export revenue reports as CSV files for accounting and tax preparation purposes.

14. Email Deliverability & List Health

Email deliverability is the single most critical technical capability of any email platform. A beautifully designed newsletter that lands in the spam folder is worthless. Deliverability is not just about technical configuration — it requires ongoing monitoring, proactive reputation management, list hygiene, and compliance with the ever-evolving policies of inbox providers like Gmail, Outlook, and Yahoo. Poor deliverability at scale can result in the platform's sending domains being blacklisted, which affects every creator on the platform.

Email Authentication

The foundation of deliverability is proper email authentication. The platform must configure and maintain three authentication mechanisms for every sending domain: SPF (Sender Policy Framework) specifies which IP addresses are authorized to send email on behalf of a domain. DKIM (DomainKeys Identified Mail) cryptographically signs every outgoing email, allowing receiving servers to verify that the email was not tampered with in transit. DMARC (Domain-based Message Authentication, Reporting & Conformance) builds on SPF and DKIM to provide a policy framework that tells receiving servers what to do with emails that fail authentication (quarantine, reject, or monitor).

Bounce Management

Bounces come in two varieties: soft bounces and hard bounces. Soft bounces are temporary delivery failures (mailbox full, server temporarily unavailable, message too large). The platform retries soft bounces up to 3 times with increasing delays (1 hour, 4 hours, 12 hours) before classifying the address as a hard bounce. Hard bounces are permanent failures (invalid address, domain does not exist, recipient rejected the email). Hard-bounced addresses are immediately suppressed and added to the global suppression list.

The bounce rate is a critical health metric. ISPs monitor bounce rates per sending domain and per sending IP. If the platform's bounce rate exceeds 2%, ISPs may throttle or block delivery. To maintain low bounce rates, the platform runs an automated list hygiene process that periodically re-validates email addresses using a third-party verification service, removes role accounts (info@, admin@, support@), and identifies dormant addresses that have not engaged in over 6 months.

Spam Complaint Handling

When a subscriber marks an email as spam, the ISP sends a complaint notification through a feedback loop (FBL). The platform must process these complaints within hours, not days. When a complaint is received, the subscriber is immediately unsubscribed from the creator's list and added to the platform-wide suppression list. The creator is notified and provided with resources on why complaints occur and how to reduce them. If a creator's complaint rate exceeds 0.1% (the industry threshold), their account is flagged for review and they may be required to implement additional measures (double opt-in, re-engagement campaigns) before sending more emails.

IP Warming & Reputation Management

New sending IPs and domains must be "warmed up" gradually to establish a positive reputation with ISPs. The platform starts sending at low volumes (100 emails/hour) and gradually increases over 2-4 weeks as engagement metrics prove the email is wanted. During the warming period, the platform prioritizes sends to the most engaged subscribers (those who have opened or clicked in the last 30 days) because their positive engagement signals help build reputation quickly.

15. Analytics Dashboard & Reporting

Analytics are how creators understand what is working and what needs improvement. The analytics dashboard must answer the questions that matter most to creators: How fast is my list growing? Which emails get the best engagement? How much revenue am I generating? Which traffic sources bring the best subscribers? The dashboard must be fast, visually clear, and actionable — numbers without context are just noise.

Core Metrics

The platform tracks four categories of metrics. Growth metrics include new subscribers per day/week/month, subscriber churn rate (unsubscribes + bounces), net subscriber growth, and subscriber source breakdown (organic, paid, network, import). Engagement metrics include open rate, click-through rate, click-to-open rate, best-performing subject lines, optimal send times, and engagement heatmaps by day of week and hour. Revenue metrics include gross revenue, net revenue (after fees and refunds), average order value, customer lifetime value, and monthly recurring revenue for subscriptions. Deliverability metrics include bounce rate, complaint rate, inbox placement rate, and domain reputation scores.

Data Pipeline

The analytics pipeline must process billions of events per month and serve dashboard queries in under 200 milliseconds. The architecture uses a Lambda-style approach with both real-time and batch processing layers. The real-time layer uses Kafka streams to update live counters (current broadcast open count, real-time subscriber growth) with sub-second latency. The batch layer runs hourly ClickHouse aggregation jobs that compute rollup metrics, trend data, and comparison analytics. Dashboard queries read from the batch layer for historical data and the real-time layer for current-period data, merging them in the application layer.

ClickHouse Schema

ClickHouse is the analytics database of choice because of its exceptional performance on aggregate queries over large datasets. The core analytics table is an append-only event log partitioned by month and ordered by (creator_id, event_type, timestamp). This sort order optimizes the most common dashboard query pattern: "show me all events of type X for creator Y in time range Z." ClickHouse's columnar storage and compression reduce the 3 billion monthly events to a manageable storage footprint of approximately 500 GB per month.

SQL
CREATE TABLE email_events
(
    event_id     UUID,
    creator_id   UUID,
    subscriber_id UUID,
    broadcast_id UUID,
    event_type   Enum8('open' = 1, 'click' = 2, 'bounce' = 3,
                       'unsubscribe' = 4, 'complaint' = 5),
    timestamp    DateTime,
    metadata     Map(String, String)
)
ENGINE = MergeTree()
PARTITION BY toYYYYMM(timestamp)
ORDER BY (creator_id, event_type, timestamp, subscriber_id)
TTL timestamp + INTERVAL 2 YEAR;

CREATE MATERIALIZED VIEW creator_daily_stats
ENGINE = SummingMergeTree()
PARTITION BY toYYYYMM(date)
ORDER BY (creator_id, date, event_type)
AS SELECT
    creator_id,
    toDate(timestamp) AS date,
    event_type,
    count() AS event_count
FROM email_events
GROUP BY creator_id, date, event_type;

Dashboard UX

The dashboard presents analytics in a hierarchical structure: a top-level overview showing the most important metrics at a glance, drill-down views for each metric category, and per-email analytics for individual broadcasts and sequences. The overview page displays subscriber growth trend, revenue trend, recent broadcast performance, and alerts for any metrics that have crossed warning thresholds. Creators can customize their dashboard by pinning the metrics they care about most and hiding others. All graphs support date range selection, comparison to previous periods, and export as PNG or CSV.

16. Third-Party Integrations

No creator email platform operates in isolation. Creators use a constellation of tools — website builders, e-commerce platforms, course platforms, CRMs, and automation tools — and the email platform must connect to all of them. Integrations fall into three categories: native integrations built and maintained by the platform, marketplace integrations built by third-party developers, and universal integration platforms like Zapier and Make.

Native Integrations

Native integrations provide the deepest, most reliable connections. The platform maintains first-party integrations with the most popular tools in the creator ecosystem: WordPress (auto-install tracking pixel, sync comments to subscriber profiles, trigger automations on new posts), Shopify (sync customer data, trigger post-purchase automations, segment subscribers by purchase history), Stripe (commerce processing, as discussed earlier), and YouTube (trigger automations when subscribers watch specific videos, sync channel subscriber data).

Zapier & Webhook Integrations

Zapier integration allows creators to connect the platform to thousands of other apps without writing code. The platform provides Zapier triggers (new subscriber, subscriber tagged, email opened, product purchased) and actions (add subscriber, remove tag, send broadcast, create product). Under the hood, Zapier integration works through webhooks: the platform sends HTTP POST requests to Zapier's webhook URL when trigger events occur, and Zapier sends HTTP POST requests to the platform's API when action events are triggered.

C#
public class WebhookService
{
    private readonly IHttpClientFactory _httpClientFactory;
    private readonly IWebhookRepository _webhookRepo;

    public async Task DispatchWebhookAsync(Guid creatorId, WebhookEvent evt)
    {
        var webhooks = await _webhookRepo.GetByCreatorAndEventTypeAsync(
            creatorId, evt.EventType);

        foreach (var webhook in webhooks)
        {
            var payload = new
            {
                event = evt.EventType,
                data = evt.Payload,
                timestamp = DateTime.UtcNow,
                webhook_id = webhook.Id
            };

            var content = new StringContent(
                JsonSerializer.Serialize(payload),
                Encoding.UTF8,
                "application/json");

            var signature = ComputeHmacSignature(
                webhook.Secret, await content.ReadAsStringAsync());
            content.Headers.Add("X-Webhook-Signature", signature);

            try
            {
                var client = _httpClientFactory.CreateClient();
                var response = await client.PostAsync(webhook.Url, content);

                if (!response.IsSuccessStatusCode)
                {
                    webhook.FailureCount++;
                    if (webhook.FailureCount > 10)
                        webhook.Status = WebhookStatus.Disabled;
                }
                else
                {
                    webhook.FailureCount = 0;
                    webhook.LastSuccessAt = DateTime.UtcNow;
                }
            }
            catch (Exception)
            {
                webhook.FailureCount++;
            }

            await _webhookRepo.UpdateAsync(webhook);
        }
    }
}

Integration Marketplace

The platform hosts a marketplace where third-party developers can publish integrations. Developers register their integration, define its triggers and actions using a declarative JSON schema, and submit it for review. The platform validates the integration's functionality, checks for data privacy compliance, and publishes it to the marketplace. Revenue sharing is not typically involved — integrations are free for creators to install and use, and the marketplace serves as a value-add that increases platform stickiness.

The integration architecture uses a plugin model where each integration runs in its own process (or container) and communicates with the core platform through the standard API. This isolation ensures that a buggy third-party integration cannot crash the core platform. Rate limiting is applied per-integration to prevent any single integration from consuming excessive API quota. Webhook delivery includes retry logic with exponential backoff, signature verification for security, and a delivery log that creators can inspect for debugging.

17. Detailed Database Schema Design

The database schema is the structural foundation of the entire platform. For a system handling 3 billion subscriber records and billions of email events per month, the schema must be designed with partitioning, indexing, and query optimization as first-class concerns. We use PostgreSQL as the primary transactional database, sharded by creator_id, with ClickHouse for analytics workloads.

Core Tables

SQL
-- Creators table (accounts)
CREATE TABLE creators (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    email           VARCHAR(255) NOT NULL UNIQUE,
    name            VARCHAR(255) NOT NULL,
    subdomain       VARCHAR(63) NOT NULL UNIQUE,
    plan            VARCHAR(20) NOT NULL DEFAULT 'free',
    stripe_account_id VARCHAR(255),
    created_at      TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    updated_at      TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

-- Subscribers table (sharded by creator_id)
CREATE TABLE subscribers (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    creator_id      UUID NOT NULL REFERENCES creators(id),
    email           VARCHAR(255) NOT NULL,
    first_name      VARCHAR(100),
    last_name       VARCHAR(100),
    state           VARCHAR(20) NOT NULL DEFAULT 'active',
    score           INTEGER NOT NULL DEFAULT 0,
    source          VARCHAR(50),
    timezone        VARCHAR(50),
    custom_fields   JSONB DEFAULT '{}',
    created_at      TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    updated_at      TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    UNIQUE(creator_id, email)
);

CREATE INDEX idx_subscribers_creator_state
    ON subscribers(creator_id, state);
CREATE INDEX idx_subscribers_custom_fields
    ON subscribers USING GIN(custom_fields);

-- Tags table
CREATE TABLE tags (
    id          UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    creator_id  UUID NOT NULL REFERENCES creators(id),
    name        VARCHAR(100) NOT NULL,
    created_at  TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    UNIQUE(creator_id, name)
);

-- Subscriber-Tag junction
CREATE TABLE subscriber_tags (
    subscriber_id UUID NOT NULL REFERENCES subscribers(id),
    tag_id        UUID NOT NULL REFERENCES tags(id),
    applied_at    TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    PRIMARY KEY (subscriber_id, tag_id)
);

CREATE INDEX idx_subscriber_tags_tag
    ON subscriber_tags(tag_id);

-- Broadcasts
CREATE TABLE broadcasts (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    creator_id      UUID NOT NULL REFERENCES creators(id),
    subject         VARCHAR(500) NOT NULL,
    html_body       TEXT NOT NULL,
    plain_body      TEXT,
    status          VARCHAR(20) NOT NULL DEFAULT 'draft',
    scheduled_at    TIMESTAMPTZ,
    sent_at         TIMESTAMPTZ,
    segment_criteria JSONB,
    stats           JSONB DEFAULT '{}',
    created_at      TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

CREATE INDEX idx_broadcasts_creator_status
    ON broadcasts(creator_id, status);

Email Events Table

SQL
-- Email events (high-volume, append-only)
CREATE TABLE email_events (
    id              BIGSERIAL,
    subscriber_id   UUID NOT NULL,
    broadcast_id    UUID,
    sequence_id     UUID,
    event_type      VARCHAR(20) NOT NULL,
    metadata        JSONB DEFAULT '{}',
    created_at      TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    PRIMARY KEY (id, created_at)
) PARTITION BY RANGE (created_at);

-- Create monthly partitions
CREATE TABLE email_events_2026_01 PARTITION OF email_events
    FOR VALUES FROM ('2026-01-01') TO ('2026-02-01');
CREATE TABLE email_events_2026_02 PARTITION OF email_events
    FOR VALUES FROM ('2026-02-01') TO ('2026-03-01');
-- ... more partitions created by automated job

CREATE INDEX idx_email_events_subscriber
    ON email_events(subscriber_id, event_type, created_at);
CREATE INDEX idx_email_events_broadcast
    ON email_events(broadcast_id, event_type);

Commerce Tables

SQL
-- Products
CREATE TABLE products (
    id                  UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    creator_id          UUID NOT NULL REFERENCES creators(id),
    name                VARCHAR(255) NOT NULL,
    description         TEXT,
    product_type        VARCHAR(30) NOT NULL,
    stripe_product_id   VARCHAR(255),
    stripe_price_id     VARCHAR(255),
    price_cents         INTEGER NOT NULL,
    currency            VARCHAR(3) NOT NULL DEFAULT 'USD',
    is_recurring        BOOLEAN NOT NULL DEFAULT FALSE,
    files               JSONB DEFAULT '[]',
    published           BOOLEAN NOT NULL DEFAULT FALSE,
    created_at          TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

-- Orders
CREATE TABLE orders (
    id                      UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    product_id              UUID NOT NULL REFERENCES products(id),
    subscriber_id           UUID NOT NULL REFERENCES subscribers(id),
    creator_id              UUID NOT NULL REFERENCES creators(id),
    amount_cents            INTEGER NOT NULL,
    currency                VARCHAR(3) NOT NULL DEFAULT 'USD',
    status                  VARCHAR(20) NOT NULL DEFAULT 'pending',
    stripe_payment_intent_id VARCHAR(255),
    stripe_subscription_id  VARCHAR(255),
    tax_cents               INTEGER NOT NULL DEFAULT 0,
    platform_fee_cents      INTEGER NOT NULL DEFAULT 0,
    created_at              TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    completed_at            TIMESTAMPTZ
);

CREATE INDEX idx_orders_creator_date
    ON orders(creator_id, created_at);
CREATE INDEX idx_orders_subscriber
    ON orders(subscriber_id);

Sequence Tables

SQL
-- Sequence definitions
CREATE TABLE sequences (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    creator_id      UUID NOT NULL REFERENCES creators(id),
    name            VARCHAR(255) NOT NULL,
    dag_definition  JSONB NOT NULL,
    version         INTEGER NOT NULL DEFAULT 1,
    status          VARCHAR(20) NOT NULL DEFAULT 'draft',
    created_at      TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

-- Per-subscriber execution state
CREATE TABLE sequence_executions (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    sequence_id     UUID NOT NULL REFERENCES sequences(id),
    subscriber_id   UUID NOT NULL REFERENCES subscribers(id),
    current_step_id UUID NOT NULL,
    status          VARCHAR(20) NOT NULL DEFAULT 'running',
    started_at      TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    last_action_at  TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    UNIQUE(sequence_id, subscriber_id)
);

CREATE INDEX idx_seq_exec_pending
    ON sequence_executions(sequence_id, status, last_action_at)
    WHERE status = 'running';

The schema uses several important design patterns. The email_events table is range-partitioned by month to keep partition sizes manageable and enable efficient time-range queries. The custom_fields column uses PostgreSQL's JSONB type with a GIN index, allowing efficient queries on arbitrary custom field values without requiring schema changes. The sequence_executions table uses a partial index on the status column to optimize the most common query pattern: finding running executions that need processing.

18. Caching Strategy

Caching is essential for a platform that serves millions of dashboard requests per day while simultaneously processing billions of email events. The caching strategy must balance freshness with performance, ensuring that creators see up-to-date data without overwhelming the database with read queries. We employ a multi-tier caching architecture that caches data at different granularities and with different TTLs based on how frequently the data changes and how critical freshness is.

Cache Tiers

Subscriber Record Caching

Subscriber records are the most frequently read data in the system. During email delivery, the email worker must load each subscriber's record to resolve merge tags, check suppression status, and record the delivery event. At 70,000 emails per second at peak, reading every subscriber record from PostgreSQL would overwhelm the database. Instead, subscriber records are cached in Redis with a 5-minute TTL and a write-through strategy: when a subscriber record is updated (tag added, custom field changed, state transitioned), the update is written to both PostgreSQL and Redis simultaneously.

C#
public class CachedSubscriberRepository : ISubscriberRepository
{
    private readonly ISubscriberRepository _inner;
    private readonly IDistributedCache _cache;
    private readonly TimeSpan _defaultTtl = TimeSpan.FromMinutes(5);

    private static readonly DistributedCacheEntryOptions _options =
        new DistributedCacheEntryOptions
        {
            AbsoluteExpirationRelativeToNow = TimeSpan.FromMinutes(5),
            SlidingExpiration = TimeSpan.FromMinutes(2)
        };

    public async Task<Subscriber> GetAsync(Guid id)
    {
        var cacheKey = $"subscriber:{id}";
        var cached = await _cache.GetStringAsync(cacheKey);

        if (cached != null)
            return JsonSerializer.Deserialize<Subscriber>(cached);

        var subscriber = await _inner.GetAsync(id);
        if (subscriber != null)
        {
            await _cache.SetStringAsync(cacheKey,
                JsonSerializer.Serialize(subscriber), _options);
        }
        return subscriber;
    }

    public async Task UpdateAsync(Subscriber subscriber)
    {
        await _inner.UpdateAsync(subscriber);
        var cacheKey = $"subscriber:{subscriber.Id}";
        await _cache.SetStringAsync(cacheKey,
            JsonSerializer.Serialize(subscriber), _options);
    }

    public async Task<List<Subscriber>> BatchGetAsync(IEnumerable<Guid> ids)
    {
        var result = new List<Subscriber>();
        var missedIds = new List<Guid>();

        foreach (var id in ids)
        {
            var cacheKey = $"subscriber:{id}";
            var cached = await _cache.GetStringAsync(cacheKey);
            if (cached != null)
                result.Add(JsonSerializer.Deserialize<Subscriber>(cached));
            else
                missedIds.Add(id);
        }

        if (missedIds.Any())
        {
            var fromDb = await _inner.BatchGetAsync(missedIds);
            foreach (var subscriber in fromDb)
            {
                var cacheKey = $"subscriber:{subscriber.Id}";
                await _cache.SetStringAsync(cacheKey,
                    JsonSerializer.Serialize(subscriber), _options);
                result.Add(subscriber);
            }
        }

        return result;
    }
}

Sequence State Caching

Sequence execution state is cached in Redis as a hash map keyed by sequence_id + subscriber_id. The hash fields include current_step_id, status, and last_action_at. This allows the sequence engine to quickly determine where a subscriber is in a workflow without querying PostgreSQL. The cache is invalidated whenever the subscriber's execution state changes — when they advance to a new step, when a timer fires, or when they exit the sequence. The invalidation is performed as part of the same database transaction that updates PostgreSQL, ensuring cache consistency.

Analytics Caching

Analytics data is cached more aggressively because slight staleness is acceptable for dashboard display. The dashboard API first checks Redis for cached analytics aggregates. If the cache is hit, the response is returned immediately. If the cache is missed, the API queries ClickHouse for the data, stores the result in Redis with a 15-minute TTL, and returns the response. Background refresh jobs update the cache before expiry for the most popular dashboards, ensuring that the most active creators always see fresh data.

19. Multi-Region & Global Distribution

A creator email platform serving 500,000+ creators worldwide must provide fast, reliable access regardless of where creators and subscribers are located. Multi-region deployment is not just about performance — it is about compliance (GDPR requires European subscriber data to remain in Europe), resilience (a region outage should not take down the entire platform), and latency (creators in Asia should not wait 3 seconds for their dashboard to load because the origin server is in Virginia).

Region Topology

The platform deploys in three primary regions: US East (Virginia) for North and South American creators, EU West (Frankfurt) for European creators, and APAC (Singapore) for Asian and Oceanian creators. Each region contains a complete deployment of all services, databases, and caches. Subscribers are assigned to the region of their creator — a creator in Germany has all their subscriber data stored in the EU West region, and all email delivery for their subscribers originates from European IPs.

Routing Strategy

The global DNS layer routes creators to their home region based on the region stored in their account profile. When a creator signs up, they select their region (or it is auto-detected based on their IP). All subsequent API requests are routed to that region's load balancer. The routing is sticky — once a creator is assigned to a region, they stay there unless they explicitly request a region migration (which involves data transfer and a brief maintenance window).

Cross-Region Replication

While each region operates independently for most operations, some data must be replicated globally. The global suppression list (bounced emails and spam complainants) must be replicated to every region to prevent suppressed addresses from receiving emails in any region. Creator authentication tokens must be globally valid so that a creator traveling abroad can access their account from any region. These global datasets are replicated using a multi-master replication pattern with conflict resolution based on last-writer-wins timestamps.

Failover & Disaster Recovery

If a region goes down, the DNS layer detects the health check failure and routes affected creators to the nearest healthy region. The creators can continue to access their dashboard and manage their account, but email delivery may be delayed until the home region recovers (because subscriber data is not fully replicated to other regions). The platform maintains point-in-time recovery backups for each region, with a 5-minute RPO (Recovery Point Objective) and a 30-minute RTO (Recovery Time Objective). Full disaster recovery drills are performed quarterly to validate that backups can be restored and services brought online within the target RTO.

20. Cost Estimation

Understanding the cost structure of a creator email platform is essential for business viability. The platform must be cost-efficient enough to offer a generous free tier (up to 10,000 subscribers) while remaining profitable on paid plans. We will estimate infrastructure costs across compute, storage, networking, third-party services, and operational overhead.

Compute Costs

Database & Storage Costs

Third-Party Service Costs

Total Monthly Cost

Revenue modeling shows that with 600,000 creators and an average revenue per user (ARPU) of $8/month across paid plans, the platform generates approximately $4.8 million per month in subscription revenue. Commerce transaction fees add another $1.5 million per month. Total monthly revenue of approximately $6.3 million comfortably covers the $286,450 infrastructure cost, leaving a healthy gross margin for engineering, support, and growth investments.

21. Interview Q&A — 10+ Senior-Level Questions

Q1: How would you handle a scenario where a creator has 2 million subscribers and schedules a broadcast for a specific time?

This is a classic capacity and scheduling challenge. The key insight is that we must pre-compute the target subscriber list and enqueue delivery jobs well before the scheduled send time — not at the moment of sending. When the broadcast is scheduled, we immediately compute the target list (applying segment filters, excluding unsubscribed and suppressed addresses), partition the list into timezone groups (if using timezone-aware scheduling), and enqueue delivery jobs into the message queue with the appropriate scheduled_at timestamp. The email workers begin consuming jobs from the queue based on the scheduled_at time, processing approximately 70,000 jobs per second at peak. For 2 million subscribers, the entire delivery takes approximately 28 seconds from the first email to the last.

Q2: How do you prevent duplicate emails from being sent if a worker crashes mid-delivery?

Duplicate prevention requires idempotency at every level. Each email job has a unique ID that is used as an idempotency key. Before sending an email, the worker checks (in Redis) whether this job ID has already been processed. If it has, the worker skips it. If it has not, the worker marks it as in-progress in Redis, sends the email via the SMTP relay, and then marks it as completed. If the worker crashes after sending but before marking as completed, the next worker that picks up the job will check the SMTP relay's delivery log (or use a local database record) to determine if the email was actually sent. The SMTP relay itself provides deduplication — most relays have built-in idempotency keys that prevent the same email from being delivered twice.

Q3: How would you design the segment computation engine to handle complex filter criteria?

Segment computation must be fast because segments are evaluated in real time when a creator views their subscriber list, when a broadcast targets a segment, and when an automation trigger fires. The approach is to translate segment filter rules into optimized SQL queries against the PostgreSQL database. A segment like "has tag 'customer' AND custom_field 'country' = 'US' AND created_at > '2025-01-01'" translates to a SQL query that uses the composite index on (creator_id, state) for the initial filter, the tag junction table for tag filtering, and a GIN index on custom_fields for custom field filtering. For frequently accessed segments, we maintain a materialized view that is refreshed every 5 minutes. The materialization trade-off is acceptable because segment membership does not need to be real-time accurate — a few minutes of staleness is fine for broadcast targeting.

Q4: How would you handle a creator who wants to send a broadcast to a segment that includes subscribers from both the US and EU regions?

This scenario exposes a fundamental tension in the multi-region architecture. If the creator is in the US but has some subscribers whose data is in the EU (perhaps they migrated regions), we cannot simply route all delivery through the US because GDPR may require EU subscriber data to be processed within Europe. The solution is a federated query approach: the broadcast service sends segment evaluation queries to both regions, merges the results, and then routes email delivery jobs to the appropriate region's worker pool. EU-bound emails are enqueued in the EU region's Kafka topic, and US-bound emails in the US region's topic. This adds latency to the pre-send computation (approximately 500ms for cross-region query merging) but ensures compliance with data residency requirements.

Q5: How would you detect and prevent abuse — a creator using the platform to send spam?

Abuse detection operates at multiple levels. At the account level, new accounts have sending limits (500 emails/day for the first 7 days) that gradually increase as reputation builds. At the broadcast level, every email passes through a spam content filter that checks for known spam patterns, blacklisted URLs, excessive image-to-text ratio, and known spam trigger words. At the delivery level, real-time bounce and complaint monitoring automatically pauses sending if thresholds are breached. At the behavioral level, machine learning models analyze sending patterns to detect anomalies — a sudden spike in sending volume, a disproportionate number of unsubscribes relative to opens, or sending to purchased email lists (detected by high bounce rates and low engagement). When abuse is detected, the account is suspended pending review, and the creator is notified with specific guidance on how to resolve the issue.

Q6: How do you handle the email template rendering pipeline at scale without becoming a bottleneck?

Template rendering is CPU-bound work that must be parallelized aggressively. Each email requires merge tag resolution, CSS inlining, tracking pixel injection, and link rewriting — approximately 0.65 milliseconds of computation per email. For a broadcast to 1 million subscribers, that is 650 seconds of single-threaded work. The solution is a render farm: email workers are deployed in a pool of 200+ instances, each running multiple threads. The broadcast service pre-splits the target list into 10,000-job batches, each enqueued as a separate message in the Kafka topic. Workers consume batches in parallel, rendering and sending emails concurrently. With 200 workers x 4 threads x 1,000 emails/second throughput per thread, the total render and send capacity is 800,000 emails/second — well above the peak requirement of 70,000/second.

Q7: How would you implement the sequence execution engine to handle millions of concurrent subscriber workflows?

The sequence engine is essentially a distributed workflow execution system. Each subscriber's execution is an independent workflow instance that progresses through a DAG of steps. The key architectural decision is to use an event-driven model rather than a polling model. Each step completion produces an event (email_sent, delay_expired, condition_evaluated) that triggers the evaluation of the next step. The events are processed by a pool of sequence workers that load the subscriber's current execution state from Redis, evaluate the current node in the DAG, and either advance the subscriber to the next step or schedule a future event (for delay nodes). This event-driven approach eliminates the need for a central scheduler and allows the engine to scale horizontally — adding more workers directly increases throughput.

Q8: How would you design the global suppression list to ensure no suppressed email ever receives an email?

The global suppression list is the most safety-critical data in the system. It must be consulted before every email send, and it must be consistent across all regions. The implementation uses a two-tier approach: a hot tier in Redis (containing the most recently added suppressions, updated in real time) and a cold tier in PostgreSQL (the complete list, replicated asynchronously). Before sending any email, the worker checks Redis for the email address. If found, the email is not sent. If not found in Redis, the email proceeds. The Redis tier is periodically synced with PostgreSQL to catch any entries that may have been missed during replication lag. The suppression list is append-only — entries are never removed — which simplifies consistency guarantees.

Q9: How would you migrate a creator with 5 million subscribers from a competitor platform without downtime?

Large migrations require a phased approach. Phase 1: Import the subscriber list via CSV or API sync, creating all subscriber records in a pending state. This can take several hours for 5 million records and should be done using bulk insert operations (COPY command in PostgreSQL) with batch sizes of 100,000. Phase 2: Re-confirm the imported list using double opt-in — send a confirmation email to all imported subscribers. This protects deliverability by ensuring every imported subscriber actually wants to receive emails. Phase 3: Gradually transition sending — start with the most engaged subscribers (those who opened an email in the last 30 days) and progressively include less engaged subscribers. Phase 4: Full cutover — once all subscribers are imported and confirmed, the creator switches their form embeds and landing pages to point to the new platform.

Q10: How would you handle a scenario where a Stripe webhook is lost and the platform's order record is out of sync with Stripe?

Webhook reliability is critical for financial correctness. We implement a reconciliation system that runs hourly and compares the platform's order records with Stripe's payment intent list via the Stripe API. Any payment intents that show as succeeded in Stripe but are not marked as completed in the platform are identified as discrepancies and automatically reconciled. Additionally, we maintain a dead letter queue for failed webhook deliveries — any webhook that fails to process after 3 retries is placed in the DLQ and flagged for manual review. The combination of periodic reconciliation and DLQ monitoring ensures that no successful payment is ever lost, even in the face of network failures or service outages.

Q11: How would you design the analytics system to support real-time open tracking on a broadcast while maintaining eventual consistency for historical data?

Real-time open tracking for a broadcast (showing "1,247 of 50,000 opened so far") requires a different architecture than historical analytics. For the real-time use case, we maintain an atomic counter in Redis keyed by broadcast_id: INCR broadcast:{id}:open_count. The tracking service increments this counter on every open event. The dashboard polls the counter every 5 seconds and displays the current value. For historical analytics, the same open events flow through Kafka into ClickHouse, where they are aggregated into daily and hourly rollup tables. The two systems are eventually consistent — the Redis counter may be slightly ahead of ClickHouse during high-traffic periods — but this is acceptable because the real-time counter is used for progress monitoring while ClickHouse powers the detailed analytics dashboard.

22. Full C# Implementation — Core Services

This section provides production-quality C# implementations for the four core services of the creator email platform: BroadcastService, SequenceEngine, SubscriberManager, and CommerceService. These implementations demonstrate the patterns, abstractions, and error handling strategies discussed throughout this article.

BroadcastService — Full Implementation

C#
public class BroadcastService : IBroadcastService
{
    private readonly IBroadcastRepository _broadcastRepo;
    private readonly ISubscriberRepository _subscriberRepo;
    private readonly IJobQueue _jobQueue;
    private readonly IEmailRenderer _renderer;
    private readonly ITemplateRepository _templateRepo;
    private readonly IEventPublisher _eventPublisher;
    private readonly ILogger<BroadcastService> _logger;

    public BroadcastService(
        IBroadcastRepository broadcastRepo,
        ISubscriberRepository subscriberRepo,
        IJobQueue jobQueue,
        IEmailRenderer renderer,
        ITemplateRepository templateRepo,
        IEventPublisher eventPublisher,
        ILogger<BroadcastService> logger)
    {
        _broadcastRepo = broadcastRepo;
        _subscriberRepo = subscriberRepo;
        _jobQueue = jobQueue;
        _renderer = renderer;
        _templateRepo = templateRepo;
        _eventPublisher = eventPublisher;
        _logger = logger;
    }

    public async Task<Broadcast> CreateDraftAsync(Guid creatorId, CreateBroadcastRequest request)
    {
        var broadcast = new Broadcast
        {
            Id = Guid.NewGuid(),
            CreatorId = creatorId,
            Subject = request.Subject,
            HtmlBody = request.HtmlBody,
            PlainBody = request.PlainBody,
            TemplateId = request.TemplateId,
            SegmentCriteria = request.SegmentCriteria,
            Status = BroadcastStatus.Draft,
            CreatedAt = DateTime.UtcNow
        };

        await _broadcastRepo.CreateAsync(broadcast);
        _logger.LogInformation(
            "Created broadcast {BroadcastId} for creator {CreatorId}",
            broadcast.Id, creatorId);

        return broadcast;
    }

    public async Task<ScheduleResult> ScheduleBroadcastAsync(
        Guid broadcastId, DateTime scheduledAt, TimezoneMode timezoneMode)
    {
        var broadcast = await _broadcastRepo.GetAsync(broadcastId)
            ?? throw new NotFoundException("Broadcast not found");

        if (broadcast.Status != BroadcastStatus.Draft)
            throw new InvalidOperationException(
                "Only draft broadcasts can be scheduled");

        broadcast.Status = BroadcastStatus.Scheduled;
        broadcast.ScheduledAt = scheduledAt;
        broadcast.TimezoneMode = timezoneMode;
        await _broadcastRepo.UpdateAsync(broadcast);

        var targetCount = await PrecomputeTargetListAsync(broadcast);
        await _eventPublisher.PublishAsync(new BroadcastScheduledEvent
        {
            BroadcastId = broadcastId,
            TargetCount = targetCount,
            ScheduledAt = scheduledAt
        });

        return new ScheduleResult
        {
            BroadcastId = broadcastId,
            TargetCount = targetCount,
            ScheduledAt = scheduledAt
        };
    }

    public async Task SendImmediatelyAsync(Guid broadcastId)
    {
        var broadcast = await _broadcastRepo.GetAsync(broadcastId)
            ?? throw new NotFoundException("Broadcast not found");

        broadcast.Status = BroadcastStatus.Sending;
        broadcast.SentAt = DateTime.UtcNow;
        await _broadcastRepo.UpdateAsync(broadcast);

        var subscribers = await _subscriberRepo
            .GetTargetSubscribersAsync(broadcast.CreatorId, broadcast.SegmentCriteria);

        var batchSize = 10000;
        var totalEnqueued = 0;

        foreach (var batch in subscribers.Chunk(batchSize))
        {
            var jobs = batch.Select(subscriber => new EmailJob
            {
                Id = Guid.NewGuid(),
                BroadcastId = broadcastId,
                SubscriberId = subscriber.Id,
                CreatorId = broadcast.CreatorId,
                ScheduledAt = DateTime.UtcNow,
                CreatedAt = DateTime.UtcNow
            }).ToList();

            await _jobQueue.EnqueueBatchAsync(jobs);
            totalEnqueued += jobs.Count;
        }

        _logger.LogInformation(
            "Enqueued {Count} email jobs for broadcast {BroadcastId}",
            totalEnqueued, broadcastId);

        await _eventPublisher.PublishAsync(new BroadcastSendingEvent
        {
            BroadcastId = broadcastId,
            TotalEmails = totalEnqueued
        });
    }

    public async Task<BroadcastStats> GetStatsAsync(Guid broadcastId)
    {
        var broadcast = await _broadcastRepo.GetAsync(broadcastId)
            ?? throw new NotFoundException("Broadcast not found");

        return new BroadcastStats
        {
            BroadcastId = broadcastId,
            Status = broadcast.Status,
            TotalRecipients = broadcast.Stats.TotalRecipients,
            Delivered = broadcast.Stats.Delivered,
            Opens = broadcast.Stats.Opens,
            UniqueOpens = broadcast.Stats.UniqueOpens,
            Clicks = broadcast.Stats.Clicks,
            UniqueClicks = broadcast.Stats.UniqueClicks,
            Bounces = broadcast.Stats.Bounces,
            Unsubscribes = broadcast.Stats.Unsubscribes,
            OpenRate = broadcast.Stats.TotalRecipients > 0
                ? (double)broadcast.Stats.UniqueOpens / broadcast.Stats.TotalRecipients * 100
                : 0,
            ClickRate = broadcast.Stats.TotalRecipients > 0
                ? (double)broadcast.Stats.UniqueClicks / broadcast.Stats.TotalRecipients * 100
                : 0
        };
    }

    private async Task<int> PrecomputeTargetListAsync(Broadcast broadcast)
    {
        var subscribers = await _subscriberRepo
            .GetTargetSubscribersAsync(broadcast.CreatorId, broadcast.SegmentCriteria);
        return subscribers.Count;
    }
}

SequenceEngine — Full Implementation

C#
public class SequenceEngine : ISequenceEngine
{
    private readonly ISequenceRepository _sequenceRepo;
    private readonly IExecutionRepository _executionRepo;
    private readonly ISubscriberRepository _subscriberRepo;
    private readonly IEmailJobQueue _emailQueue;
    private readonly ITimerQueue _timerQueue;
    private readonly ITagRepository _tagRepo;
    private readonly IEventPublisher _eventPublisher;
    private readonly ILogger<SequenceEngine> _logger;

    public SequenceEngine(
        ISequenceRepository sequenceRepo,
        IExecutionRepository executionRepo,
        ISubscriberRepository subscriberRepo,
        IEmailJobQueue emailQueue,
        ITimerQueue timerQueue,
        ITagRepository tagRepo,
        IEventPublisher eventPublisher,
        ILogger<SequenceEngine> logger)
    {
        _sequenceRepo = sequenceRepo;
        _executionRepo = executionRepo;
        _subscriberRepo = subscriberRepo;
        _emailQueue = emailQueue;
        _timerQueue = timerQueue;
        _tagRepo = tagRepo;
        _eventPublisher = eventPublisher;
        _logger = logger;
    }

    public async Task EnrollSubscriberAsync(Guid sequenceId, Guid subscriberId)
    {
        var sequence = await _sequenceRepo.GetAsync(sequenceId)
            ?? throw new NotFoundException("Sequence not found");

        var existing = await _executionRepo.GetAsync(sequenceId, subscriberId);
        if (existing != null)
        {
            _logger.LogWarning(
                "Subscriber {SubscriberId} already enrolled in sequence {SequenceId}",
                subscriberId, sequenceId);
            return;
        }

        var execution = new SequenceExecution
        {
            Id = Guid.NewGuid(),
            SequenceId = sequenceId,
            SubscriberId = subscriberId,
            CurrentStepId = sequence.GetRootStepId(),
            Status = ExecutionStatus.Running,
            StartedAt = DateTime.UtcNow,
            LastActionAt = DateTime.UtcNow
        };

        await _executionRepo.CreateAsync(execution);
        _logger.LogInformation(
            "Enrolled subscriber {SubscriberId} in sequence {SequenceId}",
            subscriberId, sequenceId);

        await AdvanceSubscriberAsync(sequenceId, subscriberId);
    }

    public async Task AdvanceSubscriberAsync(Guid sequenceId, Guid subscriberId)
    {
        var maxIterations = 100;
        var iteration = 0;

        while (iteration < maxIterations)
        {
            var execution = await _executionRepo.GetAsync(sequenceId, subscriberId);
            if (execution == null || execution.Status != ExecutionStatus.Running)
                return;

            var sequence = await _sequenceRepo.GetAsync(sequenceId);
            var node = sequence.GetNode(execution.CurrentStepId);

            if (node == null)
            {
                execution.Status = ExecutionStatus.Completed;
                await _executionRepo.UpdateAsync(execution);
                return;
            }

            switch (node.Type)
            {
                case StepType.Email:
                    await HandleEmailNode(execution, node);
                    break;
                case StepType.Delay:
                    await HandleDelayNode(execution, node);
                    return;
                case StepType.Condition:
                    await HandleConditionNode(execution, node, subscriberId);
                    break;
                case StepType.Tag:
                    await HandleTagNode(execution, node, subscriberId);
                    break;
                case StepType.Goal:
                    execution.Status = ExecutionStatus.Waiting;
                    await _executionRepo.UpdateAsync(execution);
                    return;
                case StepType.End:
                    execution.Status = ExecutionStatus.Completed;
                    await _executionRepo.UpdateAsync(execution);
                    return;
            }

            iteration++;
        }
    }

    private async Task HandleEmailNode(SequenceExecution execution, SequenceNode node)
    {
        var subscriber = await _subscriberRepo.GetAsync(execution.SubscriberId);
        var job = new EmailJob
        {
            Id = Guid.NewGuid(),
            SubscriberId = execution.SubscriberId,
            SequenceId = execution.SequenceId,
            SequenceExecutionId = execution.Id,
            EmailTemplateId = node.EmailTemplateId,
            ScheduledAt = DateTime.UtcNow
        };
        await _emailQueue.EnqueueAsync(job);

        execution.CurrentStepId = node.NextStepId;
        execution.LastActionAt = DateTime.UtcNow;
        await _executionRepo.UpdateAsync(execution);
    }

    private async Task HandleDelayNode(SequenceExecution execution, SequenceNode node)
    {
        var fireAt = DateTime.UtcNow.Add(node.DelayDuration);
        await _timerQueue.ScheduleAsync(new TimerJob
        {
            ExecutionId = execution.Id,
            SequenceId = execution.SequenceId,
            SubscriberId = execution.SubscriberId,
            FireAt = fireAt
        });
        execution.Status = ExecutionStatus.Waiting;
        execution.LastActionAt = DateTime.UtcNow;
        await _executionRepo.UpdateAsync(execution);
    }

    private async Task HandleConditionNode(
        SequenceExecution execution, SequenceNode node, Guid subscriberId)
    {
        var subscriber = await _subscriberRepo.GetAsync(subscriberId);
        var result = await EvaluateConditionAsync(node.Condition, subscriber);

        execution.CurrentStepId = result
            ? node.YesBranchStepId
            : node.NoBranchStepId;
        execution.LastActionAt = DateTime.UtcNow;
        await _executionRepo.UpdateAsync(execution);
    }

    private async Task HandleTagNode(
        SequenceExecution execution, SequenceNode node, Guid subscriberId)
    {
        await _tagRepo.AddTagAsync(subscriberId, node.TagName);

        execution.CurrentStepId = node.NextStepId;
        execution.LastActionAt = DateTime.UtcNow;
        await _executionRepo.UpdateAsync(execution);
    }

    private async Task<bool> EvaluateConditionAsync(
        SequenceCondition condition, Subscriber subscriber)
    {
        return condition.Type switch
        {
            ConditionType.HasTag => subscriber.Tags.Contains(condition.TagName),
            ConditionType.CustomFieldEquals => subscriber.CustomFields
                .TryGetValue(condition.FieldName, out var val) &&
                val == condition.ExpectedValue,
            ConditionType.OpenedEmail => await _executionRepo
                .HasOpenedEmailAsync(subscriber.Id, condition.BroadcastId),
            ConditionType.ClickedLink => await _executionRepo
                .HasClickedLinkAsync(subscriber.Id, condition.LinkUrl),
            _ => false
        };
    }

    public async Task HandleTimerFiredAsync(Guid executionId)
    {
        var execution = await _executionRepo.GetByIdAsync(executionId);
        if (execution == null) return;

        var sequence = await _sequenceRepo.GetAsync(execution.SequenceId);
        var node = sequence.GetNode(execution.CurrentStepId);

        execution.Status = ExecutionStatus.Running;
        execution.CurrentStepId = node.NextStepId;
        execution.LastActionAt = DateTime.UtcNow;
        await _executionRepo.UpdateAsync(execution);

        await AdvanceSubscriberAsync(execution.SequenceId, execution.SubscriberId);
    }
}

23. Conclusion & Key Takeaways

Building a creator email platform like ConvertKit (Kit) is a formidable engineering challenge that spans distributed systems, real-time event processing, financial technology, and user experience design. Throughout this guide, we have dissected every major component of the system — from the high-level architecture down to individual database indexes — demonstrating the depth of technical thinking required to build and operate a platform serving 500,000+ creators and billions of subscribers.

Architecture Summary

The platform is built on six foundational pillars. 1. Separation of concerns: Creator-facing services, email delivery pipeline, and analytics pipeline operate independently, allowing each to scale and fail without affecting the others. 2. Event-driven design: Kafka and RabbitMQ provide durable message queues that decouple producers from consumers, enabling backpressure handling and graceful degradation. 3. Horizontal scalability: Every service is stateless (or uses externalized state via Redis), allowing the platform to scale by adding instances rather than upgrading existing ones. 4. Data partitioning: Sharding by creator_id co-locates related data for efficient queries, while time-based partitioning of event tables keeps write performance constant as data grows. 5. Multi-region deployment: Regional isolation ensures GDPR compliance and low latency, with selective global replication for critical data like the suppression list. 6. Cost efficiency: The free tier is economically viable because the platform optimizes for email delivery throughput (the dominant cost driver) rather than compute or storage.

Key Design Decisions

Several design decisions stood out as critical to the platform's success. Idempotency everywhere: Every email send, every payment processing, every webhook delivery uses idempotency keys to prevent duplicate side effects. This is non-negotiable in a system that handles real money and must not spam subscribers. Global suppression list: Sharing suppression data across all creator accounts prevents bad actors from using new accounts to reach previously suppressed addresses. This is a platform-level safety mechanism that protects the reputation of every creator on the platform. Sequence versioning: Making automation DAGs immutable per version prevents the chaos of modifying live workflows. Creators can update their automations freely knowing that in-progress subscribers will not be disrupted. Write-through caching: For subscriber records, we write to both cache and database simultaneously, avoiding the consistency pitfalls of cache-aside patterns for critical operational data.

Lessons for System Design Interviews

If this topic appears in a system design interview, focus on these key themes. Scale estimation: Start with the number of creators and subscribers, derive email volume, and use that to size the delivery infrastructure. The 70,000 emails/second peak throughput number is a good anchor point. Asymmetric workloads: Explain why the read path (dashboard) and write path (email delivery) have fundamentally different performance characteristics and why they should be architected independently. Data model depth: Show that you understand the difference between tags, segments, and custom fields, and explain why segments are computed on demand rather than materialized. Real-world trade-offs: Discuss the tension between real-time analytics (Redis counters) and historical analytics (ClickHouse), and why eventual consistency is acceptable for one but not the other. Compliance awareness: Mention GDPR, CAN-SPAM, and the global suppression list to demonstrate that you think beyond pure technical architecture.

What We Covered

This guide covered 23 comprehensive sections spanning the complete system design of a creator email platform. We began with understanding the product and its unique position in the creator economy, moved through requirements gathering and capacity estimation, designed the data model and API surface, built the high-level architecture with Mermaid diagrams, and then deep-dived into each major subsystem: broadcasts, automations, subscriber management, commerce, landing pages, the creator network, paid newsletters, deliverability, analytics, integrations, database schema, caching, multi-region deployment, and cost estimation. We concluded with 11 senior-level interview questions and production-quality C# implementations of the core services.

The creator economy is growing rapidly, and the platforms that provide the infrastructure for creators to own their audience and monetize their content will be among the most important technology companies of the next decade. Building the email platform that powers these creators is both a significant technical challenge and a meaningful contribution to the creator ecosystem. I hope this guide has provided you with the architectural knowledge and practical insights to design, build, and operate such a platform at scale.

For further reading, explore our companion guides on Substack system design, Stripe payment processing architecture, and distributed email delivery at scale. These resources provide additional depth on the subsystems we discussed here and complement the knowledge gained from this comprehensive creator email platform design guide.