This is a great question actually, and something I've been struggling with a lot in any multi-player systems I've been trying to design.
I've come-up with the following scheme, but I haven't been able to battle-test it yet, and its definitely more geared towards 'slower' games like an RTS and not to shooters or fighting games.
Instead of making these changes immediately in a system I would introduce the concept of commands. Anything that changes that every client/server needs to know about generates a command. For example if the user presses the 'build' button a BuildCommand should be generated.
That BuildCommand should be sent to the server, the server should verify the requirements for this command (does the player have enough resources?) and then validate that command in a message to all listeners.
Clients handle new validation messages at the beginning of each frame. So the new entities/components are created at that time and present for simulation during the entire frame.
Using this scheme you never directly make changes to your entities/components without the others knowing about it.
To make this scheme work even better you could consider running all clients in lock-step and including a frame-number in the validation message so that every client handles a message in the same frame. Be careful though this will lead your game to run as slow as your slowest/laggiest client.
Not every change to an entity/component needs to generate a command. Sound systems, particle systems, graphical systems, etc.. can basically do their own thing because without the other clients needing to know about it. If your simulation is deterministic you will in general only need commands for things that happened because of user input.
Hope this helps! I'd love to know if you settle on this, or another, strategy and what your reasoning was.