Three Practical Spring Boot Solutions for Auto‑Cancelling Orders After 30 Minutes

Introduction

In transaction‑heavy systems such as e‑commerce, food delivery, ticketing, and online education, an order that remains unpaid for 30 minutes must be automatically cancelled. A naïve @Scheduled scan works for a few thousand orders per day but quickly runs into database load, duplicate processing across multiple instances, race conditions with payments, and unreliable message handling.

Business Boundary and Order State Model

Only orders in the UNPAID state are eligible for automatic cancellation. The state machine is:

CREATED
  |
  v
UNPAID  --------------------> PAID
  |                           |
  | timeout / user cancel    | fulfill / refund
  v                           v
CANCELLED                FINISHED

Key states and their cancellation permission: CREATED: not cancellable directly; creation workflow must finish first. UNPAID: can be auto‑cancelled. PAID: cannot be auto‑cancelled. CANCELLED and FINISHED: terminal, no further cancellation.

The safe SQL that updates an order only when it is still UNPAID is the backbone of every solution:

UPDATE t_order
SET status = 'CANCELLED',
    cancel_reason = 'TIMEOUT',
    cancel_time = NOW(),
    version = version + 1,
    update_time = NOW()
WHERE id = ?
  AND status = 'UNPAID';

Recommended Table Design

A table that stores expire_time explicitly (instead of computing it on the fly) enables efficient index usage and supports per‑order timeout configurations.

CREATE TABLE t_order (
  id BIGINT PRIMARY KEY,
  user_id BIGINT NOT NULL,
  order_no VARCHAR(64) NOT NULL,
  status VARCHAR(32) NOT NULL,
  total_amount DECIMAL(18,2) NOT NULL,
  expire_time DATETIME NOT NULL,
  pay_time DATETIME NULL,
  cancel_time DATETIME NULL,
  cancel_reason VARCHAR(64) NULL,
  version INT NOT NULL DEFAULT 0,
  create_time DATETIME NOT NULL,
  update_time DATETIME NOT NULL,
  UNIQUE KEY uk_order_no (order_no),
  KEY idx_status_expire_id (status, expire_time, id),
  KEY idx_user_create_time (user_id, create_time)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

Important indexes: idx_status_expire_id(status, expire_time, id) – supports scanning UNPAID orders that have passed their expiration. id placed at the end of the composite index to enable cursor‑based pagination. expire_time as a separate column to allow different timeout lengths per order.

Three Main Solutions – Overall Comparison

Scheduled polling – minute‑level precision, moderate throughput, low operational complexity, suited for small‑to‑medium systems.

RabbitMQ delayed queue – second‑to‑minute precision, high throughput, high reliability, appropriate for medium‑to‑large systems.

Time‑bucket + MQ + compensation – minute‑level precision, very high throughput, strong scalability, ideal for ultra‑large, sharded environments.

Solution 1 – Scheduled Task Polling

Core Idea

Periodically query expire_time <= NOW() AND status='UNPAID', batch‑cancel, then wait for the next schedule.

Problems with a Naïve Implementation

Scanning the whole table can exhaust memory.

Multiple service instances may process the same batch.

Deep pagination with OFFSET becomes slower as the table grows.

No built‑in timeout for a single run; tasks may pile up.

Lack of failure retry and monitoring.

Production‑Ready Implementation

Uses a distributed lock (Redisson), cursor pagination ( id > lastId), bounded execution time, and a thread‑pool for parallel cancellation.

@Component
@RequiredArgsConstructor
@Slf4j
public class OrderTimeoutScanJob {
    private static final String LOCK_KEY = "job:order-timeout-scan";
    private static final int BATCH_SIZE = 300;
    private static final long MAX_RUNNING_MILLIS = 50_000L;

    private final OrderMapper orderMapper;
    private final OrderCancelService orderCancelService;
    private final RedissonClient redissonClient;
    private final ThreadPoolTaskExecutor orderCancelExecutor;

    @Scheduled(cron = "0 */1 * * * ?")
    public void scanExpiredOrders() {
        RLock lock = redissonClient.getLock(LOCK_KEY);
        boolean locked = false;
        try {
            locked = lock.tryLock(0, 70, TimeUnit.SECONDS);
            if (!locked) {
                log.info("Order timeout scan already running on another node, skipping");
                return;
            }
            long start = System.currentTimeMillis();
            long lastId = 0L;
            int total = 0;
            while (System.currentTimeMillis() - start < MAX_RUNNING_MILLIS) {
                List<Long> orderIds = orderMapper.selectExpiredUnpaidIds(lastId, BATCH_SIZE);
                if (orderIds.isEmpty()) break;
                CompletableFuture<?>[] futures = orderIds.stream()
                    .map(id -> CompletableFuture.runAsync(() -> cancelSafely(id), orderCancelExecutor))
                    .toArray(CompletableFuture[]::new);
                CompletableFuture.allOf(futures).join();
                total += orderIds.size();
                lastId = orderIds.get(orderIds.size() - 1);
            }
            log.info("Order timeout scan completed, processed={}, costMs={}", total, System.currentTimeMillis() - start);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            log.warn("Order timeout scan interrupted", e);
        } finally {
            if (locked && lock.isHeldByCurrentThread()) lock.unlock();
        }
    }

    private void cancelSafely(Long orderId) {
        try {
            orderCancelService.cancelTimeoutOrder(orderId);
        } catch (Exception e) {
            log.error("Order timeout cancellation failed, orderId={}", orderId, e);
        }
    }
}

Thread‑Pool Configuration

@Configuration
public class OrderJobExecutorConfig {
    @Bean
    public ThreadPoolTaskExecutor orderCancelExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setThreadNamePrefix("order-cancel-");
        executor.setCorePoolSize(8);
        executor.setMaxPoolSize(16);
        executor.setQueueCapacity(2_000);
        executor.setKeepAliveSeconds(60);
        executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
        executor.initialize();
        return executor;
    }
}

Optimization Checklist

Use cursor pagination ( id > lastId) instead of OFFSET.

Only fetch id in the scan; retrieve full order details when cancelling.

Employ distributed locks (Redisson, ShedLock, XXL‑JOB) or sharding to avoid duplicate work.

Limit each scan round by time or batch count.

Ensure the composite index (status, expire_time, id) exists.

When to Choose

Suitable for daily order volume < 100 k, tolerance of 1–5 minutes delay, and teams that prefer not to manage a message broker.

Solution 2 – RabbitMQ Delayed Queue

Core Idea

When an order is created, a 30‑minute delayed message is published. After the delay the message lands in a consumer queue; the consumer checks the order state and, if still UNPAID, performs an idempotent cancellation.

Delay Implementations

TTL + Dead‑Letter Exchange – native RabbitMQ feature, simple but can suffer from head‑of‑queue blocking.

x‑delayed‑message plugin – per‑message delay, easier to use but requires plugin installation and careful monitoring of backlog.

RabbitMQ Configuration

@Configuration
public class RabbitOrderDelayConfig {
    public static final String DELAY_EXCHANGE = "order.delay.exchange";
    public static final String DELAY_QUEUE = "order.delay.queue";
    public static final String CANCEL_EXCHANGE = "order.cancel.exchange";
    public static final String CANCEL_QUEUE = "order.cancel.queue";
    public static final String CANCEL_ROUTING_KEY = "order.cancel";

    @Bean
    public DirectExchange orderCancelExchange() {
        return ExchangeBuilder.directExchange(CANCEL_EXCHANGE).durable(true).build();
    }

    @Bean
    public Queue orderCancelQueue() {
        return QueueBuilder.durable(CANCEL_QUEUE)
            .deadLetterExchange("order.cancel.dlx.exchange")
            .deadLetterRoutingKey("order.cancel.failed")
            .build();
    }

    @Bean
    public Binding orderCancelBinding() {
        return BindingBuilder.bind(orderCancelQueue()).to(orderCancelExchange()).with(CANCEL_ROUTING_KEY);
    }

    @Bean
    public Queue orderDelayQueue() {
        return QueueBuilder.durable(DELAY_QUEUE)
            .ttl(30 * 60 * 1000)
            .deadLetterExchange(CANCEL_EXCHANGE)
            .deadLetterRoutingKey(CANCEL_ROUTING_KEY)
            .build();
    }

    @Bean
    public DirectExchange orderDelayExchange() {
        return ExchangeBuilder.directExchange(DELAY_EXCHANGE).durable(true).build();
    }

    @Bean
    public Binding orderDelayBinding() {
        return BindingBuilder.bind(orderDelayQueue()).to(orderDelayExchange()).with("order.delay.30m");
    }
}

Order Creation – Sending the Delayed Message

@Service
@RequiredArgsConstructor
@Slf4j
public class OrderCreateService {
    private final OrderMapper orderMapper;
    private final RabbitTemplate rabbitTemplate;
    private final OrderMessageLogMapper messageLogMapper;

    @Transactional(rollbackFor = Exception.class)
    public Long createOrder(CreateOrderCommand cmd) {
        Long orderId = IdGenerator.nextId();
        LocalDateTime now = LocalDateTime.now();
        OrderDO order = new OrderDO();
        order.setId(orderId);
        order.setUserId(cmd.userId());
        order.setOrderNo(OrderNoGenerator.next());
        order.setStatus(OrderStatus.UNPAID.name());
        order.setTotalAmount(cmd.totalAmount());
        order.setExpireTime(now.plusMinutes(30));
        order.setCreateTime(now);
        order.setUpdateTime(now);
        orderMapper.insert(order);

        OrderTimeoutMessage message = new OrderTimeoutMessage(orderId, order.getOrderNo(), order.getExpireTime());
        messageLogMapper.insertPending(orderId, RabbitOrderDelayConfig.DELAY_EXCHANGE, "order.delay.30m", JsonUtils.toJson(message));

        TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronization() {
            @Override
            public void afterCommit() { sendDelayMessage(orderId, message); }
        });
        return orderId;
    }

    private void sendDelayMessage(Long orderId, OrderTimeoutMessage message) {
        CorrelationData correlationData = new CorrelationData(String.valueOf(orderId));
        rabbitTemplate.convertAndSend(RabbitOrderDelayConfig.DELAY_EXCHANGE, "order.delay.30m", message,
            msg -> {
                msg.getMessageProperties().setDeliveryMode(MessageDeliveryMode.PERSISTENT);
                msg.getMessageProperties().setMessageId(String.valueOf(orderId));
                return msg;
            }, correlationData);
    }
}

Consumer – Idempotent Cancellation

@Component
@RequiredArgsConstructor
@Slf4j
public class OrderTimeoutRabbitConsumer {
    private final OrderCancelService orderCancelService;
    private final OrderMapper orderMapper;

    @RabbitListener(queues = RabbitOrderDelayConfig.CANCEL_QUEUE)
    public void onMessage(OrderTimeoutMessage msg, Message raw, Channel channel) throws IOException {
        long tag = raw.getMessageProperties().getDeliveryTag();
        Long orderId = msg.orderId();
        try {
            OrderDO order = orderMapper.selectById(orderId);
            if (order == null) {
                log.info("Order not found, ack, orderId={}", orderId);
                channel.basicAck(tag, false);
                return;
            }
            if (!OrderStatus.UNPAID.name().equals(order.getStatus())) {
                log.info("Order status changed, no cancel, orderId={}, status={}", orderId, order.getStatus());
                channel.basicAck(tag, false);
                return;
            }
            if (order.getExpireTime().isAfter(LocalDateTime.now())) {
                log.warn("Order not yet expired, ack, orderId={}, expireTime={}", orderId, order.getExpireTime());
                channel.basicAck(tag, false);
                return;
            }
            orderCancelService.cancelTimeoutOrder(orderId);
            channel.basicAck(tag, false);
        } catch (BizTemporaryException e) {
            log.warn("Temporary exception, requeue, orderId={}", orderId, e);
            channel.basicNack(tag, false, true);
        } catch (Exception e) {
            log.error("Cancellation failed, dead‑letter, orderId={}", orderId, e);
            channel.basicNack(tag, false, false);
        }
    }
}

Reliability Settings

spring:
  rabbitmq:
    publisher-confirm-type: correlated
    publisher-returns: true
    template:
      mandatory: true
    listener:
      simple:
        acknowledge-mode: manual
        prefetch: 50
        retry:
          enabled: false

Key Pitfalls

TTL + DLX can suffer from head‑of‑queue blocking when many messages share the same delay.

The delayed‑message plugin adds operational overhead and may cause memory pressure under heavy backlog.

Never delete a delayed message after payment; simply check the order state during consumption.

Solution 3 – Time‑Bucket + MQ + Compensation

Why Time Buckets?

When order volume reaches millions, a single delay queue becomes a bottleneck. Grouping orders that expire within the same minute into a bucket allows batch processing, reduces per‑order scheduling overhead, and scales horizontally.

Architecture Overview

Order Service → write expire_time
   ↓
Bucket Scheduler (writes to t_order_timeout_bucket)
   ↓
MQ / Redis ZSet / Scheduler Table
   ↓
Consumer Cluster → idempotent cancel
   ↓
Order DB + downstream services

Compensation Job (periodic scan of overdue UNPAID orders)

Bucket Table

CREATE TABLE t_order_timeout_bucket (
  id BIGINT PRIMARY KEY,
  bucket_time DATETIME NOT NULL,
  shard_no INT NOT NULL,
  order_id BIGINT NOT NULL,
  status VARCHAR(32) NOT NULL,
  retry_count INT NOT NULL DEFAULT 0,
  next_retry_time DATETIME NULL,
  create_time DATETIME NOT NULL,
  update_time DATETIME NOT NULL,
  UNIQUE KEY uk_order_id (order_id),
  KEY idx_bucket_shard_status (bucket_time, shard_no, status, id),
  KEY idx_retry_time (status, next_retry_time)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

Fields: bucket_time – minute‑level bucket (e.g., 2024‑06‑23 15:30). shard_no – enables parallel consumers. status – PENDING / PROCESSING / DONE / FAILED. retry_count and next_retry_time – support limited retries.

Adding an Order to a Bucket

@Service
@RequiredArgsConstructor
public class OrderTimeoutBucketService {
    private static final int SHARD_COUNT = 64;
    private final OrderTimeoutBucketMapper bucketMapper;

    public void addToTimeoutBucket(Long orderId, LocalDateTime expireTime) {
        LocalDateTime bucketTime = expireTime.withSecond(0).withNano(0);
        int shardNo = Math.floorMod(orderId.hashCode(), SHARD_COUNT);
        TimeoutBucketDO bucket = new TimeoutBucketDO();
        bucket.setId(IdGenerator.nextId());
        bucket.setBucketTime(bucketTime);
        bucket.setShardNo(shardNo);
        bucket.setOrderId(orderId);
        bucket.setStatus("PENDING");
        bucket.setCreateTime(LocalDateTime.now());
        bucket.setUpdateTime(LocalDateTime.now());
        bucketMapper.insertIgnore(bucket);
    }
}

Shard‑Aware Consumer (XXL‑JOB example)

@Component
@RequiredArgsConstructor
@Slf4j
public class OrderTimeoutBucketJob {
    private static final int BATCH_SIZE = 500;
    private static final int TOTAL_SHARDS = 64;

    private final OrderTimeoutBucketMapper bucketMapper;
    private final OrderCancelService orderCancelService;

    @XxlJob("orderTimeoutBucketJob")
    public void execute() {
        int shardIndex = XxlJobHelper.getShardIndex();
        int shardTotal = XxlJobHelper.getShardTotal();
        for (int shardNo = shardIndex; shardNo < TOTAL_SHARDS; shardNo += shardTotal) {
            processShard(shardNo);
        }
    }

    private void processShard(int shardNo) {
        LocalDateTime nowBucket = LocalDateTime.now().withSecond(0).withNano(0);
        long lastId = 0L;
        while (true) {
            List<TimeoutBucketDO> records = bucketMapper.selectDueBuckets(nowBucket, shardNo, lastId, BATCH_SIZE);
            if (records.isEmpty()) break;
            for (TimeoutBucketDO rec : records) {
                if (bucketMapper.markProcessing(rec.getId()) == 0) continue;
                try {
                    orderCancelService.cancelTimeoutOrder(rec.getOrderId());
                    bucketMapper.markDone(rec.getId());
                } catch (Exception e) {
                    log.error("Bucket cancel failed, bucketId={}, orderId={}", rec.getId(), rec.getOrderId(), e);
                    bucketMapper.markFailed(rec.getId());
                }
                lastId = rec.getId();
            }
        }
    }
}

Compensation Scan (fallback)

@Component
@RequiredArgsConstructor
@Slf4j
public class OrderTimeoutCompensateJob {
    private static final int BATCH_SIZE = 500;
    private static final Duration COMPENSATE_DELAY = Duration.ofMinutes(5);

    private final OrderMapper orderMapper;
    private final OrderCancelService orderCancelService;
    private final RedissonClient redissonClient;

    @Scheduled(cron = "0 */5 * * * ?")
    public void compensate() {
        RLock lock = redissonClient.getLock("job:order-timeout-compensate");
        boolean locked = false;
        try {
            locked = lock.tryLock(0, 4, TimeUnit.MINUTES);
            if (!locked) return;
            long lastId = 0L;
            int total = 0;
            LocalDateTime threshold = LocalDateTime.now().minus(COMPENSATE_DELAY);
            while (true) {
                List<Long> ids = orderMapper.selectExpiredUnpaidIdsBefore(threshold, lastId, BATCH_SIZE);
                if (ids.isEmpty()) break;
                for (Long id : ids) {
                    try { orderCancelService.cancelTimeoutOrder(id); }
                    catch (Exception e) { log.error("Compensation cancel failed, orderId={}", id, e); }
                }
                total += ids.size();
                lastId = ids.get(ids.size() - 1);
            }
            log.info("Compensation completed, total={}", total);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        } finally {
            if (locked && lock.isHeldByCurrentThread()) lock.unlock();
        }
    }
}

Advantages

Horizontal scalability – add more XXL‑JOB executors or consumer instances.

Avoids full‑table scans – each shard processes only its own bucket.

Built‑in retry via bucket status and retry_count.

Easy monitoring – bucket backlog, failure count, processing latency.

High‑Concurrency Engineering Concerns

Payment vs. Timeout Race

Both payment and timeout use conditional updates; whichever succeeds first determines the final state. Example SQL for payment:

UPDATE t_order
SET status = 'PAID',
    pay_time = NOW(),
    update_time = NOW(),
    version = version + 1
WHERE id = ?
  AND status = 'UNPAID'
  AND expire_time > NOW();

And for timeout (shown earlier). The WHERE status='UNPAID' clause guarantees mutual exclusion.

Do We Need Distributed Locks?

Locks can reduce duplicate work but never replace the conditional update. Recommended hierarchy:

Database conditional update (must).

Idempotent side‑effect tables (e.g., inventory release log).

Distributed lock (optional, for hotspot mitigation).

Idempotent Side‑Effect Table Example

CREATE TABLE t_order_cancel_action (
  id BIGINT PRIMARY KEY,
  order_id BIGINT NOT NULL,
  action_type VARCHAR(64) NOT NULL,
  status VARCHAR(32) NOT NULL,
  create_time DATETIME NOT NULL,
  UNIQUE KEY uk_order_action (order_id, action_type)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

Before releasing stock, insert a row with action_type='RELEASE_STOCK'. If the insert succeeds, perform the release; otherwise skip because another node already did it.

Local Message Table – Reliable MQ Publishing

CREATE TABLE t_order_message_log (
  id BIGINT PRIMARY KEY,
  biz_id BIGINT NOT NULL,
  message_type VARCHAR(64) NOT NULL,
  exchange_name VARCHAR(128) NOT NULL,
  routing_key VARCHAR(128) NOT NULL,
  payload TEXT NOT NULL,
  status VARCHAR(32) NOT NULL,
  retry_count INT NOT NULL DEFAULT 0,
  next_retry_time DATETIME NULL,
  create_time DATETIME NOT NULL,
  update_time DATETIME NOT NULL,
  UNIQUE KEY uk_biz_type (biz_id, message_type)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

A scheduled job retries messages whose status is PENDING or FAILED, updating the status on successful publish.

Preventing Task Pile‑up

Limit consumer prefetch to avoid pulling too many messages at once.

Thread‑pool with bounded queue and CallerRunsPolicy to naturally throttle.

Set timeouts and circuit breakers on downstream calls (inventory, coupon, notification).

Hotspot protection per user/SKU.

Compensation jobs process a limited batch per run.

Clock Synchronisation

All DB updates use NOW() for the authoritative timestamp.

Application servers should run NTP.

Monitor cancel_time - expire_time to detect drift.

Why Not Use Redis Key Expiration

Redis keyspace notifications are lazy, not a reliable message queue, can lose events during consumer downtime, and are vulnerable to cluster failover. Use them only as a cache or rate‑limit aid, not as the sole trigger for order cancellation.

Pre‑Launch Checklist

Database

Composite index (status, expire_time, id) exists.

Cancellation and payment SQL contain status='UNPAID' condition.

No deep OFFSET pagination.

If sharding, ensure every shard is scanned by the scheduler.

Message Queue

Publisher confirms enabled.

Mandatory returns enabled.

Consumers use manual ACK.

Dead‑letter queue configured with retry limits.

Metrics for queue depth and consumer lag are collected.

Business Idempotency

Inventory release, coupon refund, and notification are idempotent.

Order cancellation events carry a unique ID.

Payment and cancellation callbacks can safely handle retries.

Observability

Track total cancellations, successes, failures, and latency ( cancel_time - expire_time).

Monitor delayed‑message backlog, dead‑letter count, and compensation job volume.

Log orderId, orderNo, traceId, expireTime, currentStatus, cancelResult, and messageId for every cancellation attempt.

Solution Selection Guidance

By Scale

Daily orders < 10 k – Spring Task or XXL‑JOB with cursor pagination.

10 k – 100 k – RabbitMQ delayed queue + local message table + compensation.

> 100 k – Time‑bucket + sharded scheduler + MQ event flow.

By Existing Infrastructure

If you already run XXL‑JOB but no MQ, start with a poll‑based job and upgrade later.

If RabbitMQ is available, adopt the delayed‑queue pattern.

If Kafka is the main event backbone, use Kafka for order creation events and a DB bucket table for scheduling.

Common Pitfalls Summary

Full‑table scans cause DB overload – use cursor pagination and indexes.

Multiple instances processing the same batch – use distributed lock or shard key.

Cancellation SQL without status='UNPAID' – may cancel paid orders.

Relying solely on Redis expiration – events can be lost; add DB compensation.

Unreliable MQ publish – use a local message table with retry.

Automatic ACK on consumer failure – leads to lost work; use manual ACK and dead‑letter.

Infinite requeue of poison messages – configure max retries and dead‑letter handling.

Non‑idempotent side effects – protect with unique action tables.

Missing compensation scan – orders can be left uncancelled if the primary path fails.

Conclusion

Automatic 30‑minute order cancellation is a classic reliable‑scheduling problem. Small systems can survive with a well‑engineered scheduled poller; medium systems benefit from RabbitMQ delayed queues with a local message log; massive, sharded systems require time‑bucket scheduling, partitioned consumers, and a robust compensation layer. Across all designs the immutable safeguards are:

Database conditional update as the final concurrency guard.

MQ‑driven triggers must be idempotent and able to tolerate duplicates.

A compensation path that does not rely on a single trigger source.

End‑to‑end consistency for inventory, coupons, notifications, and risk checks.

In short, production‑grade order timeout cancellation demands thoughtful architecture, precise state checks, idempotent side‑effects, and a safety net of compensation.