Whether to choose TCP or UDP often depends on the mechanics and needs of the game. For example, First Person Shooter games often rely on UDP because of the minimal network overhead for exchanging information between two end points.
Using UDP does mean that packets could get lost or received out of order and your protocol and systems need to be prepared to handle this situation. There are UDP software solutions on the market which address these needs. See things like Raknet or ENet for examples.
Using TCP generally implies a bit more network overhead but offers you the reliable stream between the two endpoints. It also makes sure that the order you send data is the same order that it gets received at the remote end point.
Some games exploit the use of both protocols to exchange different data depending on whether the packet is order dependent or needs reliable delivery. Information that is important and should be received in order is sent via TCP and the other information exchanged via UDP that perhaps isn't as important or if it is lost will be resynced when the next UDP packet arrives.
Regarding the Entity Component System, you'll likely have this system running on both the server and client. You'll have the more heavy weight version on the server side where all the rules and logical systems exist. On the client end, its mostly just the rendering aspects of the Entity Component System with some minor logical systems that make sense to delegate to the client such as physics.
There are several ways to keep these entities synchronized. The first thing to keep in mind is that you will often have two types of Entities, Local and Networked. There are also two categories of Components, Local and Networked.
Local Entities are things such as perhaps spawning an object to point the player in a specific direction that wouldn't be necessary on other player screens that could see your avatar. A good example of this is the Archaeology surveyor object in World of Warcraft. It is purely a client side local entity when you use the Survey ability.
Generally you'd have some ID framework in place which allows the server to assign the unique IDs to network managed entities and their networked components. For local entities and components, those are purely managed by the client side only. For example, we use a 32-bit number where one of the bits on the high order end of the number represents local or networked.
Synchronizing the dynamic content from the server to the client is generally based on an concept that the avatar has a Field of Interest (FOI) circumference about them based on their current position. Anything that is within, enters, or leaves this FOI is sent to the client and it responds accordingly. Things like terrain, buildings, and water are all static content, usually delivered when the game gets installed. So this information isn't sent to the client. It's thing slike NPCs, weather changes, other players that get transmitted. Here's an example exchange from our game.
C>S: Account 'crancran' login realm Deep Earth.
S>C: Client connected
S>C: Sending Player Data to client
S>C: Player current location is 1049.0031, 1.984, 75.0494, Map Id 2.
S>C: Game Object Update - Spawn NPC 1234 - Object entered client FOI.
S>C: Game Object Update - Spawn NPC 1235 - Object entered client FOI.
S>C: Map Id 2 Current Weather is Rain.
/* player begins to move */
C>S: Player has moved. Present position is currently 1052.948, 1.984, 73.0478.
S>C: Game Object Update - Spawn NPC 99 - Object entered client FOI.
S>C: Game Object Update - Despawn NPC 1234 - Object left client FOI.
HTH.
