Ensuring Data Consistency Without Native Transactions in MongoDB

Background: The story introduces a scenario where a user’s order is marked as paid but the associated lucky bag (digital gift) is not sent due to a failure in updating the bag record, highlighting the inconsistency caused by the lack of transaction support in MongoDB 3.0.

Original Code: The original implementation updates the order status, saves the order, updates the lucky bag status, saves the bag, updates inventory, and finally marks the order as successful, all without any transactional guarantees. If any step fails after the first, the system ends up with partially applied changes.

try {
    order.status = "已支付"; // step 1
    order.save();
    luckyBag.status = "已发送"; // step 2
    luckyBag.save();
    goodCounts.count -= 1; // step 3
    goodCounts.save();
    order.status = "订单成功"; // step 4
    order.save();
} catch (excption e) {
    logError();
}

SQL Transaction Comparison: The article shows a typical SQL transaction where all steps are wrapped in start transaction , commit , and rollback to guarantee atomicity.

start transaction
  try {
    update order
    update luckyBag
    commit
  } catch (excption e) {
    rollback
  }
end transaction

Optimization Attempts: Two refactorings are discussed. The first moves all save() calls to the end, reducing the window of inconsistency but still leaving a risk if the final saves fail. The second approach suggests using asynchronous retry queues or delayed retries to handle failures.

Compensation Strategies: The article enumerates several compensation mechanisms, including: Immediate retry with exponential back‑off. Queueing failed operations in a database or Redis for later processing. Automatic or manual refunds when compensation cannot be performed. Alerting operations staff via WeChat template messages, SMS, or DingTalk bots. These measures aim to achieve eventual consistency even when the underlying data store lacks native transaction support.

Final Solution: A flowchart‑based compensation design is presented, where each step’s failure triggers specific remedial actions such as refunds, inventory rollback, or lucky‑bag re‑issuance, ensuring that the system can recover from partial failures and maintain data integrity.