I am just curious as to what the “architecture limitations” are that would keep you from being able to use the Broker. Based on the problem description, the Broker would fit perfectly.
Assuming that you truly cannot use the Broker (and based on that, I’m assuming that 3rd party “queueing engines” are also out of the question), all that is left is for you to build your own. Now, queueing is a concept that can be implemented in many ways, using many different technologies, so it will depend on how much time you want to put into it.
One very simple way would be to use a file as your queue. Get the data, append to a file, and close the connection. Then have a scheduled service, read and process the data, then delete the file. You need to be careful here and account for when the reader and writer are accessing the file at the same time. This can be easily addressed by renaming or moving the file before doing anything with it.
If you have a database table available, you can use a similar concept as the one above, but insert rows into the table (instead of appending to file), and read and delete rows from the table (instead of deleting file.)
If you need other suggestions, I could tell you a couple more. None will be as good as using the Broker though.