To achieve distributed synchronisation, you need a designated single master model, ideally on a separate game server. Control events go to that, get timestamped, the interactions of everything going on gets calculated, and timestamped update events get sent out. Replays can be done just by storing and replaying the update events.
As the model is running on a separate server, you can't even give the view const (synchronous) access to it. General purpose MVC isn't really the right approach, it is more:
model -> event stream -> local model -> view
^ |
| v
selector <- action stream <- controller
Where the two streams are definitely asynchronous and probably UDP, so lossy.
Avoid multithreading, if you have any it should be entirely localised within one of the above components (for example thread pooling within the selector, one thread per zone in the model).
For a lot of games, for performance reasons you will need to break that model and have the controller update some parts of the local model directly (e.g the way you can walk around in Wow with your internet connection unplugged). This will definitely lead to sync problems, but probably can't be avoided for a realtime game on a network with ping time > human reaction time.