A far sync node is like a "router", a means of getting your redo from your primary to another destination as fast as possible. So a typical configuration is:

primary ------ sync transport ------- far sync node ------- async transport ---------- standby database

So transactions on your primary are being transmitted synchronously to your far sync node. The standby node might be *slighty* out of data, because the redo logs are being transmitted asynchronously.

So if your primary node get destroyed, your far sync node is still OK, it will continue to send any outstanding logs to the standby until the standby has "caught up". The benefit here is that

- your redo logs are protected (because they are on the far sync node)
- primary performance is not impacted (because you located the far sync node "close" to the primary)
- the standby can be a long distance away and over a slower network without impacting production response time but still guaranteeing no data loss.

Hope this helps.

Here is a good whitepaper on the subject

https://www.oracle.com/technetwork/database/availability/farsync-2267608.pdf