one of the bits missing from the picture is how big is each inbound request. 200 x 10 bytes/min is a different problem to 100 * 1000 bytes/min for example.

If your inbound requests are less than 200 bytes for instance, it might make sense to not write the data into a file, but instead the request as the nameof the file itself. That way, the receiving task only need create an empty file in the queue directory, the processing task need only read the directory entries, perhaps sorting them by timestamp, to have the information it needs to proceed. Skipping the need to open the file would probably save a fair amount of time.

Another possibility is to not use permenant storage at all. Have the receiving task forward the requests directly to the processing task using sockets or even named pipes. If the volumes and delays are such that you encounter buffer overflows doing that, then the next step would be to have a third task in the chain who's job is to simply act as a buffer (and possibly logger). The receiver passes the requests to the buffer via ne socket, it stores them in memory (and optionally logs them to disc) and feeds them to the processing task on demand via a second socket or pipe. Any replies from the processing task could either go directly back to the reciever for return to the caller, or via the buffer depending on their size and costs.

So many possibilites, but much easier to make suggestions if you gave a clearer picture of the sizes and uses of the data involved.