There is no “synchronization” because there is no defined state for servers to reach. Protocol simply allows to exchange messages in formatted text files between two nodes. What happens to them next is not defined (and may vary greatly).
A server might decide to exchange messages in groups A, B, C… with peers X, Y, Z. Choice of peers depends on their capacity, working hours, geographic location, network position, personal connections, access to dedicated lines… Choice of groups depends on popularity, space requirements, personal preferences, user requests… Some of them allow messages to spread step-by-step to all or almost all of the network, those are global groups. Some of them are only shared by a couple of servers or exist on a single server, those are local. Nothing prevents you from making a “boobble.shmoobble.goobble” group and stating that it's the central most important point of all Usenet. You only need to make all the rest believe it. Then there are additional complexities and tools to deal with batch transfers, figuring out which messages have not yet been seen by a peer since the previous interchange (you don't want X to send lots of updates to Z, then Y to take the same long time sending mostly the same updates to Z), choice of best next hop (routing, manual load balancing), and so on.
Of course, when synchronization is needed — say, for group moderator to be able to delete spam message from many servers holding that group instead of each admin doing that on each server independently, and to prevent reintroduction and further spread of the message, — it results in hairy ball of hacks on top of original architecture, and ad-hoc external trust channels, like with signatures. Understandably, Usenet appeared in a hierarchical and controlled professional environment (users were bound by formal and informal rules), then it was re-purposed for free for all operation.
A server might decide to exchange messages in groups A, B, C… with peers X, Y, Z. Choice of peers depends on their capacity, working hours, geographic location, network position, personal connections, access to dedicated lines… Choice of groups depends on popularity, space requirements, personal preferences, user requests… Some of them allow messages to spread step-by-step to all or almost all of the network, those are global groups. Some of them are only shared by a couple of servers or exist on a single server, those are local. Nothing prevents you from making a “boobble.shmoobble.goobble” group and stating that it's the central most important point of all Usenet. You only need to make all the rest believe it. Then there are additional complexities and tools to deal with batch transfers, figuring out which messages have not yet been seen by a peer since the previous interchange (you don't want X to send lots of updates to Z, then Y to take the same long time sending mostly the same updates to Z), choice of best next hop (routing, manual load balancing), and so on.
Of course, when synchronization is needed — say, for group moderator to be able to delete spam message from many servers holding that group instead of each admin doing that on each server independently, and to prevent reintroduction and further spread of the message, — it results in hairy ball of hacks on top of original architecture, and ad-hoc external trust channels, like with signatures. Understandably, Usenet appeared in a hierarchical and controlled professional environment (users were bound by formal and informal rules), then it was re-purposed for free for all operation.