I would like to have a designed software architecture evaluated by you. Maybe someone of you has a better idea or at least suggestions for optimization.
Scenario:
It is a web application with a REST API backend. In this web application, data can be changed in a table (inline editing). As soon as a user changes data in this table, all other users should also see the changed data immediately. Data changes in the table happen very often, so that hundreds of requests could be sent to the API per minute. So the solution has to be fast and should not load the server unnecessarily.
Solution:
To notify all other clients we already have a solution, we use Azure SignalR for this. The problem to solve is how the other clients get the changed data. Although each client could send a simple GET request to the API and the API computes a new response object for each GET request but if hundreds of clients do this at the same time there will be problems.
Solutions which I have excluded so far:
The first GET request from a client which gets the changed data from the API causes the API to cache the generated response object. This solution would be technically the easiest to implement, but it won't work because a lot of clients receive the notification about changed data at the same time. All clients request the changed data at the API in parallel and therefore there is no request which generates the cache before.
The POST/PUT endpoint, which stores the data in the database, also simultaneously generates a response object and stores it in the cache. All other clients can then directly access the response object in the cache. I also discarded this solution because it means additional computing time in the POST/PUT endpoint and increases the response times of these endpoints.
Current solution:
I have attached a sketch of my solution, I hope it is halfway understandable drawn. Basically it is that the response object is precalculated before all other clients are notified about the data change. So all other clients can get the new response object directly from the cache. The key feature, however, is that the POST/PUT endpoint does not create the response object itself, but passes it on to a background process. The POST/PUT endpoint can thus respond quickly while a separate process is generating the cache and notifying all other clients.
More ideas
Here are a few more ideas, which are not yet included in the sketch but might make sense.
- You could put a MessageQueue between API and background process (Azure Storage Queue, Azure Service Bus, RabbitMQ etc.). This would increase reliability if the background process is not available for a few seconds. If the background process is reachable it can process the queue. In systems with many components there is always the danger that one component fails. What do you think about this?
I already thank everyone who takes the time to have a look at it.
