Imagine you walk into a physical clothing store. You pick up a jacket, try it on, walk toward the checkout counter with it in your hand — and then your phone rings. You take the call, walk out of the store and forget the jacket at the counter. A good store employee would notice this and, if they had your phone number, they might call you later and say, “Hey, we still have that jacket you liked, would you like us to hold it for you or ship it to your home?” That is exactly what a checkout abandonment recovery system does, except it happens automatically, at massive scale, across millions of customers, using software instead of a human employee.

In online shopping, a “cart” is a temporary holding area where a customer places items they intend to buy. Cart abandonment happens when a customer adds one or more items to this cart but leaves the website or app without completing the payment step. Industry-wide studies by groups like the Baymard Institute have repeatedly found that the average online cart abandonment rate sits between 65% and 80%. In plain terms, out of every ten shopping carts created on an average e-commerce site, somewhere between six and eight are abandoned. That is an enormous amount of lost revenue sitting right at the final step of the buying journey, which makes cart recovery one of the highest-leverage systems any e-commerce company can build.

The concept of “recovering” a lost sale is not new. Mail-order catalog companies in the early 20th century used to send follow-up postcards to customers who had requested a catalog but never placed an order. What has changed is the speed and precision. Modern systems can detect abandonment within minutes, understand exactly which products were left behind, know which channel (email, SMS, push notification, or even a phone call) the customer prefers and personalise the message using real-time inventory, pricing and even weather or local-event data.

Early e-commerce platforms in the late 1990s and early 2000s ran simple batch jobs — usually a nightly cron job that scanned a database table for carts that had not been updated in the last 24 hours, then sent a single templated email to every one of them. This worked, but it was slow, generic and could not react to real-time customer behaviour. As traffic grew and customer expectations rose, companies moved toward event-driven architectures, where every customer action (add to cart, remove from cart, view a product, start checkout) is published as an event the instant it happens. This shift, combined with the growth of managed message queues like Apache Kafka and cloud-native notification services, is what makes today’s cart recovery systems near-instant, highly personalised and able to operate at the scale of hundreds of millions of events per day.

It is also worth noting how this system has evolved alongside broader shifts in software architecture itself. In the monolithic-application era, cart abandonment logic was often just another module bundled inside the same application that handled product catalogs and checkout — simple to build, but hard to scale or evolve independently. The rise of service-oriented architecture and later microservices allowed this logic to be pulled out into its own independently deployable component. More recently, the rise of managed cloud infrastructure — serverless functions, managed Kafka offerings and third-party notification APIs — has lowered the barrier to building a genuinely event-driven recovery pipeline, so that even mid-sized companies without a large platform engineering team can now operate a system that would have required a dedicated infrastructure team just a decade ago. Understanding this historical arc is useful context for a system design interview, because it shows the interviewer that the design choices in this article are not arbitrary — they reflect lessons the industry learned the hard way over roughly two decades of e-commerce evolution.

Before designing any system, we must be precise about the problem we are solving. A checkout abandonment recovery system exists to answer three questions, continuously, for every active shopper on a platform:

1. Detection — Has this customer’s cart gone inactive long enough to be considered “abandoned”?
2. Decision — If abandoned, should we reach out, through which channel, with what content and when?
3. Delivery and measurement — Did the outreach get delivered, did the customer come back and did they actually complete the purchase?

Why does this matter so much from a business point of view? Because the customer has already done the hardest part of the funnel — they found a product, decided they liked it and expressed clear buying intent by placing it in the cart. Recovering even a small percentage of these abandoned carts is often far cheaper and more effective than acquiring a brand-new customer through advertising. Many e-commerce teams report that cart-recovery emails alone can recover between 3% and 10% of abandoned revenue and well-tuned multi-channel systems (email plus SMS plus push plus retargeting ads) can push that number higher.

Why is this a hard system design problem?

On the surface, “send an email if the cart is idle for 30 minutes” sounds simple. In practice, at scale, this becomes a genuinely difficult distributed systems problem for several reasons:

Quantifying the business opportunity

To understand why engineering leadership funds entire teams to build this system, it helps to walk through a rough back-of-envelope calculation. Suppose a mid-sized e-commerce platform sees 1,000,000 carts created per day, with an average cart value of ₹1,500 and an abandonment rate of 70%. That means 700,000 carts, worth roughly ₹1.05 crore in potential revenue, go unpurchased every single day. If a well-tuned recovery system lifts recovery by just 5 percentage points over the organic baseline, that translates into roughly ₹5.25 lakh in recovered revenue per day — well over ₹19 crore a year — from a single feature. This is exactly the kind of calculation that justifies the engineering investment in real-time detection infrastructure rather than a “good enough” nightly batch job.

Breaking the funnel into stages

It also helps to separate “abandonment” into sub-stages, because different customers abandon for different reasons and may need different treatment:

Let us now design the full system, box by box. Every component below is deliberately labelled the way it would appear in a real production architecture diagram, including the entry-point components like the API Gateway and Load Balancer, so you can see exactly where every piece sits in the request path.

Component-by-component explanation

Every box in the diagram above plays a distinct role. Let us walk through each one, what it is, why it exists and a practical example.

API Gateway

The API Gateway is the single front door that every client request passes through before reaching any backend service. It is responsible for authenticating the request (checking that the customer’s session token is valid), applying rate limits so no single client can overload the system, routing the request to the correct downstream service based on the URL path and terminating TLS so backend services do not each need to manage certificates. In our system, when a customer adds an item to their cart from the mobile app, that request first hits the API Gateway, which validates the customer’s auth token before forwarding it to the Cart Service. Companies like Netflix and Amazon use API gateways (Zuul, Kong, AWS API Gateway) precisely for this centralised control point.

Load Balancer

Behind the gateway sits a Load Balancer, which distributes incoming traffic across multiple identical instances of each backend service. Without it, all traffic would hit a single server instance, which would become a bottleneck and a single point of failure. The load balancer continuously performs health checks and stops sending traffic to any instance that becomes unhealthy. During a flash sale, when cart-update traffic might spike 20x in minutes, the load balancer works together with auto-scaling groups to spread that load across newly launched instances.

Cart Service

This microservice owns the lifecycle of the shopping cart: adding items, updating quantities, removing items and calculating running totals. Every time the cart changes, it writes to the Cart Database and publishes a CartUpdated event onto the Event Bus. This is the most important integration point for our abandonment detection pipeline, because every signal we need starts here.

Order Service

This service handles the actual checkout and payment process. When a customer successfully completes payment, it publishes an OrderPlaced event. This event is what tells the Abandonment Detector to cancel any pending reminders for that cart — nobody wants to receive a “you forgot something” email minutes after they already paid.

Event Bus (Kafka)

The Event Bus is the backbone that decouples all the producers (Cart Service, Order Service) from all the consumers (Abandonment Detector, Analytics Warehouse). Apache Kafka is the industry-standard choice here because it can durably store an ordered log of events, supports very high throughput and allows multiple independent consumers to read the same stream without interfering with each other.

Abandonment Detector

This is a stateful stream-processing service, commonly built with Kafka Streams, Apache Flink or a custom windowed job. It maintains, for every active cart, a timer of “time since last meaningful activity”. When that timer crosses a configured threshold without a corresponding OrderPlaced event, it emits an AbandonmentDetected event.

Rules Engine

Not every abandoned cart deserves the same treatment. The Rules Engine applies business logic — for example, “only trigger a reminder if cart value is above ₹500” or “wait 30 minutes for the first nudge, 24 hours for the second, 72 hours for the third”. This is often implemented as a lightweight rules engine (Drools, or a simple configuration-driven service) so that marketing teams can change thresholds without redeploying code.

Notification Orchestrator

This is the brain of the re-engagement decision. It decides which channel to use (email, SMS, push), personalises the message using data from the Segmentation Service and User Profile Service, applies frequency capping so customers are not spammed and publishes the final message request to the appropriate delivery queue.

Delivery services (email, SMS, push)

These are typically thin wrapper services around third-party providers — Amazon SES or SendGrid for email, Twilio or MSG91 for SMS and Firebase Cloud Messaging (FCM) or Apple Push Notification service (APNs) for mobile push. They handle provider-specific formatting, retries and delivery-status webhooks.

User Profile Service

This service is the source of truth for customer contact details (email, phone, push token), communication preferences and consent flags. The Notification Orchestrator queries it before sending anything, both to know how to reach the customer and to confirm the customer has not opted out. Keeping this as its own service (rather than folding it into the Cart or Order service) means contact-detail changes, consent updates and preference-centre features can evolve independently of the shopping experience.

Segmentation Service (Customer Data Platform)

This service classifies customers into behavioural segments — for example, “frequent high-value shopper”, “price-sensitive first-time visitor” or “previously churned customer” — by combining purchase history, browsing behaviour and demographic data. The Notification Orchestrator uses these segments to decide message tone, discount eligibility and even whether to reach out at all (a customer who abandons carts constantly without ever converting might be excluded from reminders to avoid wasting sending reputation and budget on a low-probability audience).

Analytics Warehouse

Every event — detection, orchestration decision, delivery and eventual recovery — is streamed into a data warehouse like Snowflake, BigQuery or Redshift. This is what allows product and marketing teams to measure recovery rate, A/B test messaging strategies and continuously improve the rules engine.

Let us go one level deeper into how the Abandonment Detector actually tracks “time since last activity” for millions of carts simultaneously, because this is usually the most interesting engineering challenge in the whole system.

Windowed state tracking

The detector uses a technique called a session window. Each cart’s session window stays “open” as long as new activity events keep arriving within the configured gap (for example, 30 minutes). If no new event arrives within that gap, the window closes and the detector treats that as a signal that the cart may be abandoned — but before firing a reminder, it double-checks that no OrderPlaced event was published for that cart.

Why Kafka Streams / Flink instead of a cron job

A stream processor keeps windowed state per key (cart ID) in a local, fault-tolerant state store and it advances time using event timestamps rather than wall-clock polling. This means the detector can process millions of cart keys concurrently, partitioned across many worker instances, with automatic failover if one instance crashes — the partition and its state simply gets reassigned to another instance.

Simplified Java implementation sketch

Below is a simplified example of how the abandonment window logic might look using Kafka Streams in Java. Real production code would include more error handling, serialisation configuration and metrics instrumentation.

public class AbandonmentDetectorTopology {

    private static final Duration INACTIVITY_GAP = Duration.ofMinutes(30);

    public Topology build() {
        StreamsBuilder builder = new StreamsBuilder();

        KStream<String, CartEvent> cartEvents =
            builder.stream("cart-events");

        KStream<String, OrderEvent> orderEvents =
            builder.stream("order-events");

        // Group cart activity by cart id and apply a session window
        KTable<Windowed<String>, CartSession> sessions = cartEvents
            .groupByKey()
            .windowedBy(SessionWindows.ofInactivityGapAndGrace(
                    INACTIVITY_GAP, Duration.ofMinutes(5)))
            .aggregate(
                CartSession::new,
                (cartId, event, session) -> session.recordActivity(event),
                (cartId, s1, s2) -> s1.merge(s2),
                Materialized.as("cart-session-store")
            );

        // When a window closes, check whether an order was placed
        sessions.toStream()
            .filter((windowedKey, session) -> session.hasItems())
            .leftJoin(
                orderEventsTable(orderEvents),
                (session, order) -> order == null
                    ? new AbandonmentDetected(session)
                    : null
            )
            .filter((key, result) -> result != null)
            .to("abandonment-detected");

        return builder.build();
    }
}

Why the left join with order events matters

The join against the order stream is the safety check that prevents false-positive reminders. If a matching OrderPlaced event exists for that cart within the same window, the pipeline suppresses the abandonment signal entirely, so the customer never receives an unnecessary “did you forget something” message right after paying.

Partitioning strategy and why key choice matters

Kafka topics are split into partitions and every event with the same key is guaranteed to land on the same partition, in the order it was produced. For cart-events, the key must be the cart ID (or user ID, if a user can only have one active cart). This guarantee is what allows the Abandonment Detector to safely maintain per-cart state without needing a distributed lock: because all events for a given cart always arrive at the same processing instance, in order, that instance can safely update its local timer without worrying about another instance racing it. Choosing a poor partition key — for example, partitioning by product ID instead of cart ID — would scatter a single cart’s events across multiple instances and make consistent state tracking far harder.

Applying the CAP theorem to this system

The CAP theorem states that a distributed system can only fully guarantee two of three properties during a network partition: Consistency, Availability and Partition tolerance. Since network partitions are a fact of life in any distributed system, the real choice is between consistency and availability. This system makes different CAP trade-offs for different components, which is a useful thing to call out explicitly in an interview:

Rate limiting and frequency capping algorithm

The Notification Orchestrator must prevent any single customer from being messaged too often, even if multiple abandoned carts or promotional triggers fire close together. A common, efficient algorithm for this is the token bucket: each customer is assigned a bucket that holds a maximum number of “send tokens” (for example, 3 marketing messages per week), tokens refill gradually over time and every outbound message consumes one token. If the bucket is empty, the message is suppressed or deferred rather than sent. This is simple to reason about, cheap to compute (a single counter and timestamp per customer in Redis) and naturally self-limiting under load.

public class TokenBucketRateLimiter {

    private final int capacity;
    private final double refillTokensPerSecond;

    public TokenBucketRateLimiter(int capacity, double refillTokensPerSecond) {
        this.capacity = capacity;
        this.refillTokensPerSecond = refillTokensPerSecond;
    }

    public boolean tryConsume(String customerId, RedisConnection redis) {
        String key = "ratelimit:" + customerId;
        long now = System.currentTimeMillis();

        BucketState state = redis.getBucketState(key);
        if (state == null) {
            state = new BucketState(capacity, now);
        }

        double elapsedSeconds = (now - state.lastRefillTime) / 1000.0;
        double refilled = Math.min(capacity,
                state.tokens + elapsedSeconds * refillTokensPerSecond);

        if (refilled < 1.0) {
            redis.saveBucketState(key, refilled, now);
            return false; // no tokens left, suppress this notification
        }

        redis.saveBucketState(key, refilled - 1.0, now);
        return true;  // token consumed, safe to send
    }
}

Concurrency considerations

Within a single Abandonment Detector instance, multiple partitions are processed by multiple threads for throughput. Because state for a given cart always lives on exactly one partition, there is no shared mutable state between threads for the same cart, which avoids the need for fine-grained locking. The only place true concurrency control matters is in the Redis-backed deduplication and rate-limiting keys, where atomic operations (Redis INCR or Lua scripts for the token bucket check-and-decrement) are used to avoid race conditions when multiple orchestrator instances might process related events close together in time.

Delivery-provider retries with exponential backoff

Third-party providers (email, SMS, push) occasionally return transient errors — a temporary rate limit, a brief outage, a network blip. Retrying immediately in a tight loop can make things worse by hammering an already struggling provider, so delivery services use exponential backoff with jitter: each retry waits progressively longer than the last, with a small random offset added so that many failed requests do not all retry at exactly the same moment and cause a synchronised thundering herd against the provider.

public class ExponentialBackoffRetry {

    private final int maxAttempts;
    private final long baseDelayMillis;

    public ExponentialBackoffRetry(int maxAttempts, long baseDelayMillis) {
        this.maxAttempts   = maxAttempts;
        this.baseDelayMillis = baseDelayMillis;
    }

    public boolean sendWithRetry(NotificationPayload payload, DeliveryClient client) {
        for (int attempt = 1; attempt <= maxAttempts; attempt++) {
            try {
                client.send(payload);
                return true;
            } catch (TransientDeliveryException ex) {
                long delay  = baseDelayMillis * (long) Math.pow(2, attempt - 1);
                long jitter = ThreadLocalRandom.current().nextLong(0, delay / 2 + 1);
                sleepQuietly(delay + jitter);
            } catch (PermanentDeliveryException ex) {
                // e.g. invalid email address, do not retry
                deadLetterQueue.publish(payload, ex.getMessage());
                return false;
            }
        }
        deadLetterQueue.publish(payload, "max retries exceeded");
        return false;
    }
}

Notice the distinction between TransientDeliveryException (worth retrying, such as a temporary rate limit) and PermanentDeliveryException (never worth retrying, such as a malformed email address). Conflating these two cases is a common mistake — retrying a permanent failure just wastes resources and delays the message from being routed to a dead-letter queue for manual inspection.

Exactly-once versus at-least-once processing

Kafka Streams supports an exactly-once processing guarantee (via transactional writes and idempotent producers) for the detection pipeline itself, meaning the internal state updates and output events are not duplicated even if a processing instance crashes and restarts mid-batch. However, this guarantee stops at the boundary of the Kafka cluster — once the Notification Orchestrator calls out to an external email provider, that external side effect is no longer covered by Kafka’s transactional guarantees. This is precisely why the deduplication key described earlier is still necessary even when the internal pipeline is configured for exactly-once semantics: exactly-once inside Kafka does not automatically mean exactly-once for the real-world side effect of sending an email.

Let us trace a single cart, end to end, from creation to either recovery or expiry.

Cart lifecycle as a state machine

This state machine view is useful because it makes explicit that a cart can be “recovered” from any stage of the reminder sequence and that reminders stop the instant recovery happens. It also shows why we cap the sequence at three reminders — beyond that point, continued messaging tends to produce diminishing returns and rising unsubscribe rates.

No system design decision comes for free and the checkout abandonment recovery system is a particularly good case study in trade-offs because it sits at the intersection of engineering complexity, customer experience and business revenue. A team building this system is not just choosing technologies — it is making a series of judgment calls about how aggressively to pursue short-term revenue recovery versus long-term customer trust and platform stability. The tables below summarise the major trade-offs, but it is worth understanding the reasoning behind each one rather than treating them as a checklist.

Build versus buy

Not every company needs to build this system from scratch. Third-party marketing automation platforms (Klaviyo, Braze, Iterable, MoEngage) offer cart-abandonment recovery as a configurable, largely no-code feature and platform-level tools (Shopify’s built-in abandoned checkout emails) handle the simplest cases automatically. Building an in-house system, as described throughout this article, becomes the right choice once a company needs tighter real-time coupling with its own inventory and pricing systems, wants full control over the data pipeline for advanced personalisation, operates at a scale where per-message third-party platform pricing becomes prohibitively expensive, or needs deep integration with proprietary recommendation and segmentation models that a generic SaaS platform cannot access. Many companies start with a third-party tool and migrate to an in-house system only once they hit one of these scaling or customisation limits — which is itself a useful lesson in incremental system evolution rather than over-engineering on day one.

At scale, this system must handle bursts of activity, especially during flash sales or festive shopping seasons like Diwali or Black Friday, when cart-event volume can spike by 10 to 20 times normal traffic within minutes.

Horizontal scaling of the Kafka pipeline

The Event Bus topic cart-events should be partitioned by cart ID (or user ID), so that all events for a given cart always land in the same partition and are processed in order by the same consumer instance. Increasing the number of partitions allows more Abandonment Detector instances to run in parallel, each owning a subset of partitions. This is the standard scaling lever in Kafka-based systems.

Backpressure and load shedding

During extreme spikes, the Notification Orchestrator can apply backpressure by prioritising high-value carts (based on cart total) over low-value ones if the delivery queues start to back up, ensuring the highest-revenue opportunities are handled first.

Caching strategy

The Cart Service uses Redis as a write-through cache in front of the primary Cart Database. Most cart reads (displaying the cart to the user) hit Redis directly, avoiding load on PostgreSQL. Cart data is also given a TTL (time to live) in Redis so that stale, long-abandoned carts do not consume cache memory indefinitely.

Latency budget example

Capacity planning example

Let us work through a rough capacity estimate for the Kafka layer during a peak sale event. Assume 50,000 cart-update events per second at peak and each event averages 1 KB in size once serialised. That is roughly 50 MB / second of write throughput into Kafka. With a replication factor of 3, actual disk write throughput across the cluster is closer to 150 MB / second. A modern Kafka broker on cloud infrastructure can typically sustain hundreds of MB / second per broker, so a cluster of 6 to 9 brokers comfortably absorbs this load with headroom for growth and broker failure. This kind of estimate — translating a business-level number (concurrent shoppers) into infrastructure sizing (brokers, partitions, consumer instances) — is exactly the skill system design interviews are testing for.

Load testing strategy

Before any major sale event, teams typically run synthetic load tests that replay a multiplied version of historical peak traffic against a staging environment that mirrors production topology. This validates three things: that auto-scaling policies actually trigger fast enough (scaling up 10 new pod replicas takes time and if it is slower than the traffic ramp, requests will be dropped or queued); that Kafka partition count is high enough to let consumer groups scale out; and that downstream third-party providers (SendGrid, Twilio) have been given advance notice of expected volume, since some providers throttle sudden traffic spikes from unfamiliar senders.

Read / write scaling asymmetry

Cart reads (customer viewing their cart) typically outnumber cart writes (adding / removing items) by a wide margin, since customers often revisit a cart page multiple times per session without changing it. This asymmetry is why the Redis read-through cache in front of the Cart Database matters so much — it absorbs the read-heavy traffic, leaving the database to handle a comparatively smaller volume of actual writes, which keeps the primary transactional store from becoming a bottleneck.

A cart-recovery outage should never mean a checkout outage. This system is designed to fail gracefully and never block the core shopping and payment path.

Isolation from the critical path

The single most important reliability principle here is that the Abandonment Detector, Rules Engine and Notification Orchestrator all sit downstream of the event bus and are entirely decoupled from the Cart and Order services. If the entire recovery pipeline goes down, customers can still add items to their cart and check out normally — they simply will not receive reminder emails until the pipeline recovers and Kafka’s durable log means no events are lost; they will simply be reprocessed once services come back up.

Replication and failover

Kafka topics are replicated across multiple brokers (typically a replication factor of 3), so the loss of a single broker does not lose data. The Abandonment Detector runs multiple instances behind a consumer group, so if one instance crashes, Kafka automatically reassigns its partitions to a healthy instance, which resumes from the last committed offset.

Idempotency and exactly-once effects

Because distributed systems can redeliver events (at-least-once delivery is the norm for Kafka in most configurations), every downstream action must be idempotent. The Notification Orchestrator uses a unique deduplication key (cart ID plus reminder sequence number) stored in Redis with a TTL, so that even if the same AbandonmentDetected event is processed twice, the customer never receives a duplicate email.

Disaster recovery

The Analytics Warehouse and event logs are backed up cross-region. In a full regional outage, the system can fail over to a secondary region using Kafka’s MirrorMaker (or a managed equivalent like Confluent’s Cluster Linking) to replicate topics across regions and the Notification Orchestrator can be redeployed in the secondary region with its state rebuilt from the replicated event log.

This system handles personally identifiable information (PII) — email addresses, phone numbers, purchase history and browsing behaviour — so security is not optional.

Authentication and authorisation

All internal service-to-service calls use mutual TLS (mTLS) or signed service tokens, so that only trusted services within the platform can publish or consume sensitive events. The API Gateway enforces OAuth2 / JWT-based authentication for all customer-facing requests before anything reaches the Cart Service.

Data minimisation and encryption

Contact details (email, phone) are encrypted at rest in the User Profile Service database and access to raw contact information is restricted to the specific delivery services that need it — the Abandonment Detector and Rules Engine, for example, never need to see a raw email address; they only need a customer ID.

Consent and opt-out enforcement

Before the Notification Orchestrator queues any message, it checks a consent flag in the User Profile Service. If a customer has opted out of marketing emails or SMS, the system must respect that instantly and permanently and every delivery service includes a one-click unsubscribe link / mechanism as required by regulations like CAN-SPAM and India’s DPDP Act, 2023.

Protecting against abuse

Rate limiting at the API Gateway prevents an attacker from artificially generating millions of fake cart events to flood the notification pipeline (a form of denial-of-service against the email / SMS sending reputation of the company). The system also validates that recipient contact details actually belong to the authenticated customer, preventing “notification bombing” of unrelated third parties.

Threat modelling the notification pipeline

Data retention

Behavioural event data (which products a customer viewed or abandoned) is valuable but also sensitive, so it should not be retained indefinitely. A typical policy retains raw event-level data for a limited window (say, 90 days) in the operational systems, while aggregated, anonymised metrics can be retained longer in the analytics warehouse for trend analysis without exposing individual customer behaviour.

Observability is what turns this from a black box into a system the team can trust and continuously improve.

Key metrics to track

Logging and tracing

Every event carries a correlation ID that is propagated from the moment the customer adds an item, through detection, orchestration and delivery, all the way to the analytics warehouse. This makes it possible to trace the entire journey of a single cart through the system using distributed tracing tools like Jaeger or Zipkin, which is invaluable when debugging why a specific customer did or did not receive a reminder.

Alerting

Dashboards (commonly built in Grafana, backed by Prometheus metrics) trigger alerts when Kafka consumer lag exceeds a threshold, when delivery success rate from a provider drops below 95%, or when the detection pipeline’s error rate spikes — all of which point the on-call engineer directly at the failing component before customers notice a degraded experience.

Service level objectives (SLOs) and error budgets

A mature team defines explicit SLOs for this system rather than relying on vague notions of “it should work well”. For example, the team might commit to: 99.9% of add-to-cart API calls complete in under 300 milliseconds; 99% of abandonment detections fire within 5 minutes of the configured threshold; and 99.5% of queued email reminders are delivered within 10 minutes. Each SLO comes with an error budget — the small allowed margin of failure — which gives the team a data-driven way to decide whether it is safe to ship a risky change (plenty of error budget remaining) or whether the team should freeze changes and focus on stability (error budget nearly exhausted).

Dashboards for different audiences

This system is naturally suited to a microservices deployment on Kubernetes, running across multiple availability zones for resilience.

Typical cloud-native deployment

• Compute: Each microservice (Cart Service, Order Service, Abandonment Detector, Notification Orchestrator, delivery services) runs as a containerised deployment on Kubernetes (EKS, GKE or AKS), with Horizontal Pod Autoscaling based on CPU and Kafka consumer lag.
• Event streaming: A managed Kafka service (Amazon MSK, Confluent Cloud, or Google Pub/Sub as an alternative) removes the operational burden of running Kafka brokers directly.
• Databases: Managed PostgreSQL (Amazon RDS / Aurora or Cloud SQL) for the Cart and Order databases, with read replicas for scaling read-heavy queries.
• Cache: Managed Redis (Amazon ElastiCache or Google Memorystore) for the Cart Service’s active-cart cache and the Notification Orchestrator’s deduplication store.
• CI/CD: Each service has its own pipeline (GitHub Actions, Jenkins or GitLab CI) that builds a container image, runs automated tests and deploys via a progressive rollout strategy (canary or blue-green) to catch regressions before they hit all traffic.

Blue-green and canary rollouts for the Rules Engine

Because the Rules Engine directly controls when and how customers are messaged, changes here are deployed with extra caution — typically a canary rollout that applies new rules to a small percentage of traffic first, with automated rollback if recovery rate or unsubscribe rate moves outside expected bounds.

Multi-region considerations

For a platform serving customers across multiple geographies (say, India and Southeast Asia), running regional deployments close to the customer base reduces latency and helps satisfy data residency requirements, since some jurisdictions require customer data to remain within national borders. Event streams can be kept region-local for day-to-day processing, with only aggregated, anonymised metrics replicated globally into a central analytics warehouse.

Cost optimisation

This pipeline can become expensive at scale if left unmanaged, mainly through two levers: third-party delivery costs (SMS in particular can cost several paisa to a few rupees per message depending on the route and country) and always-on compute for stream processing. Common cost controls include batching low-priority notifications (e.g., grouping multiple low-value cart reminders into a single digest rather than sending them individually), choosing cheaper delivery channels (push notifications are essentially free compared to SMS) when a customer has the app installed and right-sizing Kafka Streams instances using consumer-lag-based autoscaling rather than static over-provisioning.

Choosing the Cart Database

A relational database like PostgreSQL is a strong default choice for the Cart Service because cart data has a clear relational structure (a cart has many items, each item references a product) and strong consistency is valuable to avoid discrepancies between what the customer sees and what actually gets charged. Some very high-scale platforms instead use a key-value or document store like DynamoDB or MongoDB for the “hot” active cart, given carts are naturally document-shaped (a single JSON blob of items per user) and benefit from that model’s fast single-key reads and writes.

Caching layer design

Redis serves two distinct purposes in this system. First, it acts as a fast read cache for active carts, avoiding repeated hits to PostgreSQL on every page load. Second, it acts as a lightweight state store for the Notification Orchestrator’s deduplication and frequency-capping logic, since these lookups need to be extremely fast (sub-millisecond) and do not require the durability guarantees of a full relational database.

Load balancing strategy

The Load Balancer in front of the Cart and Order services uses a round-robin or least-connections algorithm across service instances, combined with sticky sessions where appropriate to keep a given customer’s requests hitting a warm cache. For the Kafka consumer layer, “load balancing” instead happens through partition assignment within a consumer group, which is a fundamentally different mechanism from HTTP load balancing but serves the same underlying purpose of even work distribution.

Sharding the Cart Database with consistent hashing

As the Cart Database grows beyond what a single PostgreSQL instance can handle, it needs to be split across multiple physical database shards. A naive approach — shard = userId % numberOfShards — works initially but causes almost every single key to move to a different shard whenever the number of shards changes, which means adding capacity requires a massive, disruptive data migration. Consistent hashing solves this by mapping both shards and keys onto a conceptual ring using a hash function; each key is owned by the next shard clockwise on the ring. When a new shard is added, it only takes over a small, contiguous slice of the ring from its immediate neighbour, meaning only a small fraction of keys need to move rather than nearly all of them. This is the same core idea used inside distributed caches like memcached and databases like DynamoDB and Cassandra.

public class ConsistentHashRing {

    private final SortedMap<Long, String> ring = new TreeMap<>();
    private final int virtualNodesPerShard;

    public ConsistentHashRing(List<String> shardIds, int virtualNodesPerShard) {
        this.virtualNodesPerShard = virtualNodesPerShard;
        for (String shardId : shardIds) {
            addShard(shardId);
        }
    }

    public void addShard(String shardId) {
        for (int i = 0; i < virtualNodesPerShard; i++) {
            long hash = hash(shardId + "#" + i);
            ring.put(hash, shardId);
        }
    }

    public String getShardFor(String cartKey) {
        long hash = hash(cartKey);
        SortedMap<Long, String> tailMap = ring.tailMap(hash);
        Long nodeHash = tailMap.isEmpty() ? ring.firstKey() : tailMap.firstKey();
        return ring.get(nodeHash);
    }

    private long hash(String input) {
        return Hashing.murmur3_128().hashString(input, StandardCharsets.UTF_8).asLong();
    }
}

The “virtual nodes” concept in this code (placing each shard at multiple points around the ring rather than just one) exists to smooth out load distribution — without it, a single unlucky hash placement could give one physical shard a disproportionate share of the key space.

Example REST API surface

POST   /api/v1/cart/items                 -> add item to cart
DELETE /api/v1/cart/items/{itemId}        -> remove item from cart
GET    /api/v1/cart                       -> retrieve current cart
POST   /api/v1/checkout                   -> begin checkout and payment
POST   /api/v1/notifications/unsubscribe  -> opt out of reminders

Internal event contracts

Because services communicate primarily through events rather than direct synchronous calls, the event schema is the real API contract of this system. A simplified CartUpdated event, defined using Avro or a JSON Schema for compatibility checking, might look like this:

{
  "eventType": "CartUpdated",
  "cartId":    "c-88213",
  "userId":    "u-51092",
  "timestamp": "2026-07-31T10:15:00Z",
  "items": [
    { "productId": "p-1001", "quantity": 2, "price": 1299.00 }
  ],
  "cartTotal": 2598.00
}

Why microservices instead of a monolith here

Splitting the Cart Service, Order Service, Abandonment Detector and Notification Orchestrator into independently deployable services means each can be scaled, deployed and evolved on its own schedule. The Notification Orchestrator, for example, changes far more often (new channels, new rules, new A/B tests) than the Cart Service, which is relatively stable. Independent deployability avoids coupling the release cadence of a rapidly iterating marketing feature to a critical, rarely-changing checkout path.

Error handling in the REST API

A well-designed Cart API returns precise, actionable error responses rather than generic failures, since the frontend needs to distinguish between different failure modes to show the right message to the customer.

{
  "error": {
    "code":              "ITEM_OUT_OF_STOCK",
    "message":           "This item is no longer available in the requested quantity",
    "productId":         "p-1001",
    "availableQuantity": 1
  }
}

Common error codes in this API surface include ITEM_OUT_OF_STOCK, CART_EXPIRED, INVALID_QUANTITY and PRICE_CHANGED — the last of which matters specifically for abandonment recovery, since a cart that sat idle for days may reference a price that has since changed and the checkout flow must clearly surface that to the customer rather than silently charging a stale price.

Event schema versioning

Because the Event Bus is the primary contract between teams, schema changes need a compatibility strategy. Using a schema registry (Confluent Schema Registry is the common choice with Avro) enforces backward-compatible changes — new fields must be optional with defaults and existing fields cannot change type — so that the Abandonment Detector, built and deployed independently by a different team than the Cart Service, never breaks when the Cart Service adds new event fields.

Additional patterns worth knowing

• Outbox Pattern: To guarantee that a database write and the corresponding event publish never drift apart (for example, a cart update saved to PostgreSQL but the matching Kafka event lost due to a crash), the Cart Service can write both the state change and the outgoing event to the same local database transaction, in an “outbox” table. A separate relay process then reads the outbox table and publishes to Kafka, guaranteeing the event is eventually published if and only if the underlying database write succeeded.
• Dead Letter Queue (DLQ): Any message that permanently fails to process (malformed event, permanently invalid contact detail) is routed to a dead letter queue rather than being silently dropped or endlessly retried, giving engineers a place to inspect and manually resolve failures without blocking the main pipeline.
• Strangler Fig Pattern: When migrating an older, batch-based abandonment system to the new event-driven architecture described in this article, teams commonly route an increasing percentage of traffic to the new system over time while the old system continues handling the remainder, rather than attempting a risky big-bang cutover.

Why the anti-patterns matter more than they first appear

Several of these anti-patterns look like reasonable shortcuts under time pressure, which is exactly why they show up so often in real systems. A synchronous notification call from within the checkout path, for instance, might work fine in initial testing when the third-party provider responds in 50 milliseconds — but the very first time that provider has a slow day, every customer’s checkout latency degrades in lockstep with it, turning an unrelated marketing dependency into a checkout-blocking incident. This is the core reason the architecture in this article insists on queues between every stage: queues do not just improve throughput, they contain the blast radius of a slow or failing downstream dependency.

Testing strategy

Testing an event-driven, multi-service system requires more than unit tests on individual functions. A well-tested implementation typically includes: unit tests for the rules engine logic (given a cart state and time elapsed, does it produce the correct decision); integration tests that spin up an embedded Kafka broker (using tools like Testcontainers) to verify the actual stream topology behaves correctly under realistic event sequences, including out-of-order and duplicate events; contract tests between the Cart Service and the Abandonment Detector to catch schema-breaking changes before they reach production; and end-to-end tests in a staging environment that verify a simulated abandoned cart genuinely results in a test email being received. Chaos-engineering style tests — deliberately killing a detector instance mid-processing — are also valuable for validating that Kafka’s consumer group rebalancing and offset recovery actually work as expected under failure.

How mature teams evolve this system over time

Very few teams build the complete architecture described in this article on day one. A realistic evolution path looks something like this: the first version is often a simple scheduled job querying the database directly for idle carts, which validates the business value of recovery emails at low engineering cost. Once that proves out and traffic grows, teams introduce an event bus and move detection to a stream-processing model to cut latency and reduce database load. As the business expands into more channels, the Notification Orchestrator becomes its own dedicated service with proper rules and frequency capping. Finally, as data science and marketing teams mature, segmentation, holdout testing and multi-armed-bandit style message optimisation get layered on top. Recognising this evolutionary path is valuable in an interview setting, because it shows an understanding that good architecture is not built all at once — it is grown deliberately in response to real, measured constraints.

Large e-commerce and travel platforms have built systems that closely mirror this architecture.

Lessons learned across the industry

A few patterns show up consistently across companies that have publicly discussed their cart recovery systems. First, the first reminder almost always outperforms the second and third combined, which is why many teams invest disproportionate effort in getting the timing and content of the very first message right. Second, including a direct visual of the actual abandoned product (rather than a generic “come back” message) reliably improves click-through rates, since it triggers recognition and reduces the friction of remembering what was in the cart. Third, SMS and push tend to have much higher open rates than email but also much higher opt-out sensitivity, so teams that over-rely on SMS often see faster erosion of that channel’s effectiveness over time compared to email.

Glossary of key terms

Q: What is the ideal time to wait before sending the first reminder?

There is no universal number, but most platforms find 30 minutes to a few hours strikes a good balance — long enough to avoid interrupting an active session, short enough that the customer’s intent is still fresh. This is exactly the kind of parameter the Rules Engine should make configurable and A/B testable.

Q: How is this different from a general marketing campaign system?

A cart abandonment system is triggered by a specific, high-intent behavioural event (an item sitting unpurchased in a cart) rather than a broad, scheduled campaign. It requires real-time event processing and per-customer state tracking, which general batch-oriented campaign tools typically are not built for.

Q: What happens if a customer abandons the cart, then adds a different item later — is that the same cart?

This depends on product design, but most systems treat the cart as a single evolving entity per customer, so adding a new item resets the inactivity timer for the whole cart rather than creating a separate abandonment record.

Q: Can this architecture support guest checkouts (customers without an account)?

Yes, but it requires capturing at least a temporary identifier (like an email entered during checkout, or a device / browser identifier) before abandonment, since without any contact information, there is no channel through which to send a reminder.

Q: How do you avoid sending a reminder for an item that has since gone out of stock?

The Notification Orchestrator performs a real-time inventory check immediately before sending, rather than relying on the inventory state captured at the moment of abandonment. If the item is out of stock, the system either substitutes similar in-stock recommendations or suppresses that reminder entirely, since driving a customer back to a dead end damages trust.

Q: Should the Abandonment Detector be built with Kafka Streams, Flink, or a simpler custom service?

Kafka Streams is a strong default when the team already runs Kafka and wants a lightweight library embedded directly in the service (no separate cluster to operate). Flink becomes more attractive at very large scale or when more advanced windowing, exactly-once processing guarantees, or complex event processing across multiple streams are required. A custom service using a scheduled-timer approach can work for smaller platforms but generally struggles to scale past a few hundred thousand concurrent carts.

Q: How does this system interact with retargeting ads (e.g., showing the abandoned product in a Google or Meta ad)?

The same AbandonmentDetected event that triggers email / SMS / push can also be published to an advertising audience-sync service, which uploads a hashed customer identifier to ad platforms for retargeting campaigns. This treats retargeting ads as simply another “channel” the Notification Orchestrator can select, subject to the same frequency-capping and consent rules as the other channels.