2 ms·
This looks great from an academic point of view, but there's at least 2 problems that concern me: 1. If you have a distributed system, soft deletes can allow y
by ldoughty 2y ago
This looks great from an academic point of view, but there's at least 2 problems that concern me:
1. If you have a distributed system, soft deletes can allow you to stop a process gracefully.. e.g.: if making a user causes provisioning of resources, if a process re-queries for the user and can't find it, you don't know if it's eventual consistency creation delay or it was created-then-deleted. Obviously you can re-query the master node, or retry, etc. Point is there's more code for every such record and depending on the code structure, you might have to go back through the chain of return code before you realize you need to repeat the query strongly consistentl.
2. If you have a HUGE delete, it might put a strain on your DB if you're relying on it to do all the work. In this example, deleting a group deleted an array of member entities. If each member entity had arrays of entities, you might be deleting (m|b|t)illions of records. While that should still be fast, will that make a hiccup in your processes for 1, 3, 4, 30 seconds? Many cloud systems force transaction limits per second, so you should have a controlled deletion process anyways