How not to ruin your data after downtime

Sometimes it’s best to create a nice interface for the users and let them fix the state of data instead of “assuming” things and try fixing it yourself after a downtime.

For example, let’s say there’s a system running background process which stopped temporarily due to server downtime.

2 days later…

The system is back up and running.

What happens now?

Carefully think whether to start the background process again.

Starting the background process might mean it’ll try to cover for missed days, and if the data is consumed by users, is time sensitive you might end up creating mess.

What you should instead do is carefully analyze how this process will handle missed days and how this might impact the users. For most application restarting the process might just work fine, but not for all.

For example, say a customer was supposed to receive 10 automatic emails, one each day.

System goes down on 5th day. Comes back on 10th. 5 days missed. They haven’t received 5 emails they were expecting.

Will the background process start sending emails again, will it send 5 missed emails on thee same day, will it send emails at all? What will it do exactly?

These are the things you should plan carefully, beforehand.

Often it comes down to letting the user decide what they want to do. Instead of assuming things. Ask the user how they want to proceed after the downtime.

#softwareengineering #softwaredevelopment #programming #database #laravel #php #sql #javascript #aws #server #webdeveloper #coder #wordpress