Balancing Data Deletion and Historical Accuracy in E-Commerce with MongoDB

Introduction

Hello friends! I’m working on an e-commerce project using MongoDB, Node.js, Express, and React. The project has been progressing smoothly and worked perfectly as my expectations. However, a critical challenge arises: how to handle product data deletion while maintaining historical accuracy. In this article, I’ll share some effective strategies for managing this issue.

Essential Modules for E-Commerce

As we know, Every e-commerce platform needs fundamental modules such as products, sellers, customers, and orders. I believe these modules are the minimum required for any e-commerce platform.

Managing Product and Order Data

In the product module, I have included all the product-related attributes, while the orders module contains the history of ordered items.

While managing CRUD operations for the Product and orders, a scenario came to mind regarding product deletion. What if a product that has already been ordered needs to be deleted? How should we handle this situation?

We need to keep the historical data consistent, but how can we retrieve the product details if the product has been deleted?

This has been a real challenge for me.

I consulted my respected teacher about this situation and arrived at some conclusions that might be suitable.

1.

Soft Delete

We can implement a soft delete instead of physically deleting a product from the collection. I think this is the simple approach. This involves adding a boolean field, such as is_deleted, to the product collection. When a product is deleted, we set this flag to true instead of removing the whole document from the collection.

By retaining the product data in the database, we can reference it for historical orders. However, if we want to retrieve products for normal queries, make sure to only fetch those where the is_deleted flag is set to be false.

Example:

{
  "_id": "12345",
  "product_name": "Example Product",
  "price": 29.99,
  "image_link": "image_link or Url",
  "is_deleted": true
}

2.

Archiving

In this scenario, instead of physically deleting products, we can move the product data to a separate archive collection. This means we maintain an active product collection for current items and an archive collection for deleted products. This approach keeps the original product table clean and focused on active products while still preserving historical data in a separate product_archive collection.

Separating active and archived data can enhance performance and simplify the management of large datasets. However, it's important to note that this approach may require handling more complex queries to retrieve data from the archived collection.

Example:

• Active Products Collection:

{
  "_id": "12345",
  "product_name": "Example Product",
  "price": 29.99,
  "image_link": "image_link or URL"
}

• Archived Products Collection:

{
  "_id": "12345",
  "product_name": "Example Product",
  "price": 29.99,
  "image_link": "image_link or URL",
  "archived_date": "2024-06-20"
}

3.

Details in order collection

In this approach, we store essential product details directly in the orders collection at the time of purchase. This includes information such as product_name, price, image_link, and other relevant attributes. By doing this, we ensure that even if the product is later deleted from the main product collection, the order will still have all the necessary data. This method helps keep our order records complete and accurate, regardless of any changes to the product collection.
This simplifies the structure, as product data is already present in order collection.

example

{
  "order_id": "67890",
  "customer_id": "54321",
  "products": [
//Might contain more products here what purchased
    {
      "product_name": "Example Product",
      "price": 29.99,
      "image_link": "image_link or URL"
    }
  ]
}

However, this approach does introduce data redundancy!!, Don't worry 😊a common occurrence in MongoDB due to its flexible schema design. 😁😁 The advantage of MongoDB’s flexibility is that you don’t need to normalize your tables, which can make handling data more straightforward in many scenarios.

What did I implement?
I implemented the soft delete technique first, as a single is_deleted key effectively solves all my problems. You can explore other techniques as well, depending on your use case and what works best for you.


Feel free to share your thoughts in the comments and suggest to me any other techniques you've found helpful. Let's collaborate and learn from each other's experiences! If you found this article useful, don't hesitate to share it with your friends and colleagues. Together, we can build even better solutions!
Thank you