A proper way to delete a user within a custom app

When designing an app, what usually comes to your mind? Is it architecting the entire app by using tools like Figma for UX (User experience) design or Lucid Chart for designing the ERD (Entity relationship diagram). Depending on what comes to mind, the fact that remains is that there's a concept at play and that involves an actual representation of what your about to build.

The first thing that you should do is plan how this app is to be designed. Tools like Jira team-managed projects can help with rapidly spinning up a project that you can use to document the steps and plan the given sprints to know how the project would progress. This also gives you access to connectors like Github where when codes are committed, they can be linked to a specific task within the project phase to either close it or move to the next task. This keeps any stakeholder or team member informed of what has been done vs tasks not yet done.

Now, that you've started something how about the data of the app or which database can be used? 

" I prefer visualizing the data types of what my app can do especially when using a database store e.g. PostgreSQL. "

• Prince Nyeche

I think using an ERD to get a sense of what the tables would look like gives a visual feel on how it can be designed. Which brings me to the title of this article, when designing your user base what are the things to consider? As a developer or someone who develops apps, it is crucial you select the right data structure to use within a database. This comes with experience to grasp instantly what to do but with proper architecture you can achieve the same step.

In various apps that I have designed, I usually start with a user representation, I have to know what a user is and how I can link various objects which may not be existing at the initial phase of the project to this user entity. That's how I would approach it but of course there are different ways and strategies. However, following proper architectural design, you would go with practices that are standardize and provide efficient use of time and effort. Having said that, back to the user representation, constructing a proper model for a user is key toward a proper app design. If you can't comprehend what a typical user in the app would look like then the app might have a blocker which might pose a problem later in the development stage.

Secondly, you should think about security and compliance, how can the app be compliant at the same time ensure that the data that will be stored is secured. Well, in today's tech sector, I believe it has become easier to detect bad architectural design as compared to 10 years ago. Although, the fact still remains; are the users who will use your app trust that their data is secured. The answer should be simple enough if you've been following industry standard in the design of your database or your data store. Also, the question of how can I delete my data is always present when it comes to compliance. Would you know how to go about this process and what will it cost you in terms of the infrastructure you're using. I like this part of when a "user" wants their data removed, why not allow them to have the ability to simply wipe their data instantly (except if needed for valid reason then it should be clearly stated in your terms).

One of the things that has helped me over the years when it comes to how I create users within any custom app, is defining how that user would be deleted. I typically go with the "soft delete" approach within the user base. This way it saves a lot of time and also allows for different approaches to be implemented. Think about it, if a user wanted to delete their account, by simply deleting it what are the problems you could likely face?

Therefore, the best approach here would be to use "soft delete" mechanism with the user table and apply whatever policy within that table that prevents the same user from being used or allow the user to be reused and removed from soft delete context if they cancel their deletion request within a set amount of time. Another step here, is that for compliance, can you delete the user data at a later time if the retention period hasn't elapsed. This has to be stated within your terms on how long is your data retention period. Finally, all these won't be possible if you don't have a means to always check when a user has been deleted or if a user who is already in soft delete needs to be active again. 

This would likely mean that you can run scheduled request on your service that would check for these tasks. Redis can be used here but another tool that can help even better is Apache Airflow. You can easily customize how your application or service functions by selectively running every task that has been scheduled. It does this efficiently and provides a stats on the success or failure rate.

In essence, the proper way to delete a user within a custom app is to always use a soft delete mechanism then schedule the user to be deleted at a later time following any retention policy that you have within the app's T&C.