What is the best architecture for a back-end connector to various APIs?

Question

PHP

Good afternoon.
At the moment, there is a system that is a connector to several APIs with complex business logic in the interval between receiving a request, sending it to the API and responding.
I want to rewrite this system for better performance, resiliency, and scalability.
The above are requirements.
Now the task.
There are several external clients for the connector's back-end. Clients can submit requests in a specific format. From some clients more, from some less, all come to one port. Let's call the request from the client Port Request.
Next, the system must pre-process the request, log it, and, according to some business logic, parallelize the request into several. Let's call these several new requests Worker Request. They already contain data to be sent to a specific API and they must be executed in parallel or asynchronously.
During this time, the parent process waits for a response from each Worker Request.
Upon receipt of all responses (or timeout errors from some APIs), the head process must post-process and form one Port Request response from all Worker Request responses, log it and give it to the client.
So one cycle of processing one request from the client should be performed.
There are several types of queries, and some queries can be dependent on the data of previous queries (i.e., for example, on one of the preprocessing queries, you need to select data from the database by ID from the previous query). Therefore, query logs are also work items that must be kept for at least 30 days.
-------
The following is a description of the current system.
The current system works exactly as described in the TOR, but the implementation is not optimal. Used php + mysql. Mysql plays the role of both storage and queue. The Port Request coming in the context of the web server is written to the database, then the business logic generates a Worker Request (N pcs), they are also written to the database. Then they are picked up by a demon in the console and parallelized through forks using the Spork library. When taken from the Worker database, a selection is made with a lock until the update. Memcached is also used to cache the response of each Worker.
The advantages of this solution are the logs in the database, i.e. you can see the request logs.
The disadvantages of this solution are in the same database, I see that scaling is difficult, the entire load falls on the database (a lot of writing and reading).
------
The essence of this survey is in ideas and suggestions - how to solve the problem in the best way? Which approaches to use (queues, forks, daemons)? What tools (gearman, redis, libraries) ? Technologies (now php, others are possible) ?
Right now I'm looking at solutions like this:

• Write query logs in Mongo. (Logs in business logic are also a working unit, and data is taken from the Port Request or Worker Request ID for work.)
  
• Organize the queue through Gearman (or others). (here it is not clear whether this will create an owerflow over the current solution, since the logs will still have to be written)
  
• It is not clear how to parallel Worker, leave forks in the same way, or make a second queue. The first queue is Port Request, the second is Worker Request.
  

Answer 1

1. Logs in mongo - I regularly see packs of articles like everything is fine in mongo - but in practice it lay down for me to insert at a load of ~ 500 large json per second.
It was about two years ago, maybe something was finished - but test this moment yourself).
If you really run into logging, I would come up with some kind of buffer in redis or even mongo with periodic (every n minutes) unloading into classic sql.
2. Rabbitmq, redis, Gearman
3. About || : I think that queues are definitely correct.
All imho)

Answer 2

Write query logs to Elasticsearch