#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.