I have a ASP.NET Core backend (with Azure Service Bus) and a Blazor Server frontend.
The purpose of the backend and the frontend is to trigger manual and automatic pushing of single data points (hereafter called the "data pushing process") to 2 different external systems (two different, unrelated APIs, that I don't control) via the backend making HTTP requests to these external systems. One HTTP request to each external system is required to push the data. The requests will carry a slightly different payload, since each system has its own contracts.
The data pushing process can be triggered by:
The user clicking a button (called the "push" button in the frontend, which results in a HTTP PUT request to the backend.
The backend receives data itself from an external service (via a different protocol). The received data can either by "ready for export" or not. If it is not ready for export, a user needs to fill out a text field on the frontend, and click the "push" button.
When a user clicks a button in the frontend, it sends a HTTP PUT request to the backend. I wish this to result in the backend sending it's own HTTP requests to 2 external systems, ie. pushing data to the two systems, when triggered by the user.
Question
- What type of coordination would be good for this scenario?
It does not seem optimal to do this with two synchronous HTTP requests in a controller method. What would be a good design (pattern) for managing the work of making the HTTP requests to the external systems?
I have considered the Saga pattern.
Notes
- It's the backend that makes the HTTP requests to the external systems.
- I need to keep track of if the data point is pushed to the external systems yet or not.
- EDIT: The order of the HTTP requests does not matter.
- EDIT: The external endpoints can return HTTP 200 and 400 codes, if upserting data succeeeds, or if the user is trying to update a data point they are not allowed to update.
- EDIT: If the request(s) fail, I would like to show an error in the frontend.