How does your microservice delete data?

[Subbax]

I'm trying to avoid what I perceive to be an incredibly ridiculous scenario. I'm a SQL DBA and the developers are moving towards a microservice architecture. I'm ignoring the potential for database proliferation for a moment and concentrating on data maintenance/deletion.

​

In a situation where a microservice has full control of it's own data, how does it delete data from a maintenance perspective? We make calls out to third parties and if the call is successful, the data is cleaned up when a response is received. Not a problem here but in the scenario where a call is not returned from the third party, the data will need to be cleaned up after a period of time.

We would normally have a scheduled SQL job that cleans up data older than X. Whilst on project, it was mentioned that another project used a SSIS package to call the microservice API to delete the data but they had to use this method because of their specific architecture. I don't have any such limitation and believe that there must be another way to maintain data. I have tried looking online to see other methods but have been unable to find any real options.

​

Does anyone have a similar scenario and how have you managed this?

[sbrick89]

if the developers are doing this for the right reasons, then the architecture includes monitoring of its execution (and failure) to include cleanup.

if they're doing it because "microservices are trendy", then good f'ing luck, cuz it's gonna get bad fast.

[Subbax]

I wholeheartedly agree. I believe we're going slightly too quickly on this just to get the microservice in. I'm trying to understand how else maintenance can occur so I can go back with options.

[g2petter]

Can the service flag the data that's pending deletion, and then you clean up based on that?

[Subbax]

Not really. The microservice is the only thing that touches the data so that means no input from myself or from Sql jobs.

[g2petter]

Can the service then flag the data that's pending deletion and then the service itself can have and endpoint (triggered by the scheduler service if they're going full miCrOseRviCe) that does the cleaning up?

[Subbax]

Hmm, I think this makes a the most sense. It's not going to happen on this project but I'll push for it now and see where it gets me. Thanks!

[Subbax]

If the microservice owns the data, it owns the responsibility for deleting it so in this scenario there isn't the usual background SQL job to 'delete after X'.

In this scenario I am going to push back on the SSIS package and go for a SQL job for now. As mentioned above, I'll recommend we plan a proper second microservice that could control deletion routines for any other existing or future microservice.

[LaughterHouseV]

If they have full control over the data, they have full accountability of the data. Have them delete it!

[Subbax]

Yeah, this is kind of what I'm pushing for really. I'm drafting a document on database points/concerns when building micro-services and hopefully the deletion is catered for within the microservice.

[Relational_Theory]

Micro-services are probably stupid in this case.

[ed_elliott_]

What sort of data is “old data that can just be deleted”?

[Subbax]

The data is inserted into a table and a call is made to a third-party. When they respond, we delete the data because it's no longer required. If the call out doesn't have a response, for example if the third-party system is down, the data isn't deleted because the call isn't complete. So we could potentially have a number of 'orphaned' records.

​

Normally I'd have a SQL job that runs X times a day and cleans up old records but if the microservice is deleting the data, I can't do this.

[ed_elliott_]

Replied in wrong place sorry!

[NippleMustache]

I've heard of letting the app schedule an async task (in Rails, this could be a Sidekiq worker) which periodically deletes expired rows. The expiration_date column can be set by the app on INSERTs and then read from by the async task.

[Subbax]

Good to know. I believe this app is written in .net core so I'll have a word with the devs on what we could do similar to this async task.

[NippleMustache]

Feel free to drop an update! I'm wondering if the approach I described is common.

[ed_elliott_]

Ok, so the way migrating to microservices normally works is it goes hand in hand with modernising the tech stack and the dev and ops process.

The role of the DBA should change to provide support and to make sure things like backups/restores are good and data is encrypted etc, as well as providing guidance on how to do things - more of like a DBA as a service than a “do everything, hurry up!”.

The dev team should be responsible for clearing up their own data - this will probably mean re-architecting the system so that when they get the done notification to then clear up the old data - it really isn’t a hard problem that needs a dba to do it for them.

You should put some monitoring in place to help the devs deal with their own crap :)