Fallback Job, the solution
How? Very simply:
- In our service we will store a flag which will confirm whether the provider’s file has been deleted correctly.
- When we execute the deletion in a normal workflow, we will wait for the provider’s response. In the event that they notify us that everything has gone OK, we will then save the flag as “DELETED”
- We will provide a PRIVATE endpoint, which will allow us to delete the records that are “NOT DELETED”
- Our Fallback Job will run every X time calling this private endpoint to delete the marked file
Endpoints / Controllers
Function that controls the requests of the DELETE endpoint.
Main and Dependency Injection
In the file “pkg/deleting/service.go” we find the logic needed to delete users. The first thing we do is try to delete the image associated with the user and, if we do not succeed, what we do first is register the error and mark the user as “to delete”. If an error has not occurred, we delete it directly from the repository/database.
Deletion Service of users who were marked
Server Validation Running
In this method, all we do is ping the server and see if it is live (StatusCode = 200)
Fallback Service Call
About the Author
Mauricio Bergallo is a Systems Engineer with extensive knowledge in a variety of programming languages. Great experience and understanding with all aspects of the software development life cycle.