NO, don't store files in a relational database
Trust me, I've learned this the hard way. One problem with applications that deal with files, is as they evolve, the users always want to store more than the application was intended to handle.
I once created an application with a document storage component meant to store Word and Excel documents. The storage component was useful enough that eventually people started storing videos in it.
I mention this because, the performance implications will be higher than you expect; this leads me to my next point.
Even if a database can handle files fine (filestream type) scaling a DB is hard, it is always the hardest part to scale. Let the db concentrate on saving and retrieving data, that way you can put off scaling it as long as possible. If your DB is busy serving a large file, those are resources not being used to serve transaction and lookup requests; its bread and butter.
Server to Server synchronization does not scale well
Your system seems over-complicated to me, I would go with a simpler design. The problem with servers fs1 and fs2 talking to each other is, as you scale, the number of paths increases exponentially.
With two servers, each server only has to ask make one synch request, for a total of 2 paths. 3 severs, there are a total of 6. With 5 servers there are 20.
synchRequests = (n-1)*(n); n = number of servers
I would simply have a dedicated DB server, and a dedicated File server that the FSn servers talk to to. If you need more complex synchronization behavior, add a dedicated Redis serve in the mix to serve as the single source of truth for non-persistent details.
The point is, don't have fs1 talking to fs2, or vice-versa, this will not scale.
Graph
[ fs1 ] [ fs2 ] [ fs3 ] [ ect ]
| | | |
+-------+---+---+-------+
|
+------------------+-------------------+
| | |
[ RDB ] [ Redis ] [ Files ]
The best of both worlds?
You can head off most of the disadvantages of storing your files in a RDB, and still get most of the advantages by segregating a completely separate DB instance and storing only your files there. This is a viable option if you don;t want to setup and maintain a file server.
A quick word about microservices
I am not sure why you would want to go the microservices route. The original intent of microservices is to get around political problems, not technical problems. For example, the server admin refuses to open any ports other than 80.
Best Answer
The approach you have described will work, as long as you have a mechanism for identifying who the user is making the request. e.g. /upload/status?uid=32343
Where this gets interesting is in how you return the information back to the user. You can make it a single hit, as you described. There are also possibilities based on redirect / refresh headers in the response as well.
However also consider using the mutli-part response. You receive the HTTP request and issue a multi-part response and send the first response immediately back to the client. you then maintain the connection and send additional partial responses back to the client every few seconds. you continue doing this until either the client closes the connection, or you identify that all the files have uploaded, at which point you send the last response finishing the multi-response HTTP response message to the client.