This is a post about high level decisions made for the architecture of a game created as the FPS Sample. tl;dr - Wondering how Jobs fit into a project of this type and scope (server authoritative, snapshot based, client side prediction, server side rollback). In general, are jobs (which are concurrent in nature) a bad idea for a snapshot based entity replication procedure? Or did the FPSSample team choose not to use Jobs based on the exigencies of bring as much of the ECS system into their own project as possible and not relying on the Jobs team's work? From what I've looked at so far, this project didn't seem to be Jobified at all! Here's what I saw: the systems derive from ComponentSystem (or a custom FPSSample subclass, <name of subclass -- think it's BaseComponentSystem). Instead of a Job System calling an Execute method, all of these Component Systems are manually created as managers and then their Update methods are called in one of the game loops which deserialize and and propagate the snapshots to the components that make up the world state. Now it's my understanding that this is a non-concurrent, Burst compiled way to go. Even if it does have immediate benefits from being Data Oriented and friendly to a non-allocating native app via IL2CPP at the end of the day. I was wondering what the design decision tree to go in this route was. Obviously it makes some sense to have all of the tickets for the loop go down on the main thread, however there seems to be a lot left on the table given that even the transport layer project has examples that use the Job System. Given that SceneEntity.cs instead of GameObjectEntity's (a facet of the Hybrid system) I wonder if there just wasn't enough time to do a version of the FPS Sample with all of the latest and greatest going into the Jobs system or if it truly is the vision to keep it working like this. Are burst / jobs a bad idea in a system that pumps snapshots through the main loop like this? I know that the transport layer sample projects have job-ified networking that waits until after FixedUpdate... I know that (custom written, non-Unity ECS) Jobs are used in big multiplayer Unity games -- so it at least seems feasible.