I referred this question: Under the GDPR, should transaction data be deleted on account deletion or on user request? which deals specifically with the use-case of e-commerce site. But still, there is a need for a generalized view on the confusion regarding GDPR's "Right to be Forgotten".
A complex business user-centric web application might have references of user throughout and a complete hard delete (completely deleting the user from database) might create lots of havoc by breaking the referential integrity in the database and thereby in the entire application.
So, is soft deleting or pseudonymizing a user a correct approach meaning the user's record won't be removed from the database completely instead, his all personal information will be updated with a pseudonym (junk phrase) in the database. On UI/UX as well instead of all personally identifiable information, a pseudonym or a generic "Deleted User" or "User #234" (just as SO do) will show up. The general reference of the User's entry in database will not even be processed/used/displayed/transmitted/sold anywhere.
Please note that I am aware that GDPR is about how the data is processed and does not hold restrictions on the technicalities and designs one follows but the actual implementation and adaptions of the same are causing several severe technical constraints and the complete refactoring of the database architecture and references which happens to complicate the business application and might even need a complete restart/reset.
For instance, a Software Engineer would know that an Email can be used as identity and the entire app revolves around UserManager
and the cookies. Moreover, many fields that are marked Required
in database models on deletion may break the app completely.
So what should be the correct approach, in context of GDPR, when a user revokes his consent in a complex architectured web application?