Single table or multiple tables for custom transfer queue Currently, I'm working on synchronizing data between two SQL Server databases on separate servers but on the same network. We'll call them A(the master database) and B(the one exposed to a web application for clients). Records updated in A must also then be updated in B, whereas new records inserted in B must also then be inserted in A. While the former is never true the other way around, there could be rare cases for the latter to be true from A to B; which is not accounted for at the moment.

To solve this, I've been developing a custom queue to transfer the data. I've linked the SQL Servers, then applied triggers to the tables so that they also copy the data to a transfer queue table. Then, I have SQL Server agent run a stored procedure periodically that checks for entries in that table, to which acts accordingly and deletes the transferred data from the queue.

My question is would it be better to maintain a single transfer queue table on each SQL Server Database or multiple queue tables for each trigger? While this doesn't really apply to B as the inserted fields to transfer are always the same, the master tables in A that could get new records inserted or updated have a variable amount of fields. I'm leaning more towards a single queue and set it up so that a trigger puts each field value as a separate record with a unique key that identifies that set so that the stored procedure can group them and insert/update them in the other database all at once. Is this the better/more efficient method or should I consider multiple queues? Thanks for any and all help!
There are a lot of options when it comes to data synchronization in SQL and there is no single best option. It all depends on what are the priorities for the solution, what is the workload, maintainability and so on.. there are also build in features like SQL Server Replication that you could use.

If you are concerned with efficiency of your solution, then I would suggest to perform tests to see how many transactions are you getting and is it a satisfactory result. 
You have to bear in mind that triggers are not the fastest things in the world, so if this becomes a bottleneck - you might want to look for other solutions.

An option for replacing triggers might be adding a timestamp or last insert/update datetime column in your data that you would reference in the synchronization procedure processing only the ones changed since last sync would improve performance. This would mean you would have to synchronize whole rows unless you implemented some more advanced logic.

You should also design your conflict handling process in case the same information gets updated on both servers between synchronizations.