I am developing an online store web app where customers place orders.
I have a collection called “orders” which stores all of the orders.
Sometimes the customer may request changes to the order, say they want to change the pickup or delivery date, or a color/size of the products, etc.
I do not want to overwrite the original order and want to keep an order history so I can trace it back.
What would be the best architecture for this?
Some ideas spinning are:
-
with each edit add a new order document in the “orders” collection with the same orderID and an updated versionNumber. I don’t like this approach because the “orders” collection will become polluted very soon and very fast
-
totally redesign the “order” object to contain a key say “orderData” which will hold the details of the order and another key “versions” which will be an array of versions and each version will be an object containing the orderData of each version. I don’t like this approach because I don’t want to dramatically alter the current structure of “orders” and end up having two totally different order documents in the same collection
-
create another collection called “order_history” and keep the edited orders there and add a new boolean property to the original order called “edited”. If true, look up the order in the history collection and get the latest version. This is bad for fetching as I will have to jump around
So, what is your experience with this? What would be the neatest solution?