Single table or multiple tables for custom transfer queue
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.