Is this architecture good for the project?

Question

Django

Hello colleagues.
I am designing a rather specific project, I would like to hear the opinion of other people about what I have designed.
The bottom line is that there are 2 servers: server1 - webmord, server2 - a certain server with files. The web is written in Django. The user can select certain options in the web interface, after which server1 must instruct server2 to archive a certain directory and allow the user to download this archive. server2 is not accessible from the outside, only on the local, and the user should be able to download only the archive that he "created". With that in mind, I came up with this idea:
A python TCP server is running on server2, which accepts commands from server1 and, based on the parameters in a separate thread, creates an archive, after which it taps on the Web API on server1, reporting that the archive is ready. As soon as the user wants to download the finished archive, server1 sends the “give me the archive” command to server2 via the same TCP server, downloads it (the archives are small, less than 1 mb, since the local area should be transferred instantly) and gives it to the client in the same http request.
Actually, the question is - is everything good here, or are there more efficient ways to implement such interaction?

Answer 1

The architecture is bad. After some time, your python tcp server will be clogged with requests and stop responding (for example, there will be a lot of requests, your python program will create many separate threads with I / O operations). Look in the direction of queues, RabbitMQ, ZeroMQ is possible and Celery will do. Yes, and a simple queue can be done on Redis. The bottom line is that server2 accepts requests, writes them to the queue. On the other hand, even if your same python program pulls the task out of the queue, does the processing and gives the answer.

Answer 2

Python
in its purest form should not have anything to do with IO /