Expanding my comment into an answer.
I'd suggest you considered using the new Change Data Capture feature instead. Synchronization of Salesforce data to an external persistent store is exactly what it's made for; it allows your application to listen for change events and provides for replay and recovery should you miss portions of the event stream (within a time window). CDC guarantees ordered delivery to your application, as well.
If you don't want to use CDC, you can also do an initial bulk load and then poll with sObject Get Updated, or its SOAP equivalent.
Data sync triggers are really hard to get right 100% of the time. You have to deal with callout limits, asynchronous Apex code, managing ordered delivery guarantees yourself (if you need to), handling error recovery and redelivery, and so forth. Lots of orgs roll quick and dirty sync triggers with @future
callouts; I really recommend not going down this path - as your enterprise systems grow in complexity it rapidly becomes unmaintainable and unreliable.
To directly answer your question: trigger by nature are not per-user; they run in system context on all relevant trigger events. You need to implement per-use logic if and only if you wish to selectively deactivate your trigger on a per-user basis. There are a variety of patterns for doing so; I think the Custom Permission route is the best of them.