Thank you Jordan I am a new grad, but I got hooked on your videos because of your jokes. Hehe I’m pretty sure I’m learning system design through laughter. i guess i would be first senior new grad engineer :D
Hey Jordan, thank you very much for your hard work. Do you mind doing a little clarification on where the load balancer is in the final diargam? Is it a part of the Master Server? Somehow I follow the whole idea until the final roadmap where I got completely confused.
The master server basically caches the zookeeper nodes which tell it which servers are responsible for which regions of the game map, and returns their address to the user accordingly. If the user is close to out of bounds in that region server, it can reach back out to the master server to get the address of the adjacent region server.
Hi, Jordan, really appreciate the content, will you consider sharing your notes in as in format, with a huge asterisk that they can be wrong. It's just that I have a couple of interviews this month and want to revise all the designs but going through the all the older videos is time consuming.
Since you are partitioning the game servers by regions (say 4 regions per game on an average), that would mean that if there are a million games running concurrently, then the system would need 4 million partitions! Am I correct in my understanding? And if yes, then will all these partitions be separate physical machines or VMs?
You are correct in terms of the number of partitions, but it is not the case that each partition needs to be a separate physical machine. Partitions are just units of work, and can be distributed as necessary (or perhaps not necessary).
played PUBG many times but never thought of building one of it lol. One quick question on dynamic partition, this sounds similar to most of the other dynamic partition (monitor load with heartbeat, prepare replica, build all connection, move some clients' connection), anything special for this case? is R1a and R1b share the same region map (or they are splitting)?
Hey Jordan, I really like your videos! They are super helpful for learning system design, as a junior I learned a lot from your videos. Also wondering if it is possible to see a design about meeting scheduler, a friend of mine meet this question during her interview, she is not sure about the database design. Curious to see a Jordan solution!
It would be great to explore how this system can be adapted for other games like Chess. While many components may remain similar, the constraint of write conflicts, storing game state may not be applicable to Chess.
I actually think chess is much easier. Game state is super constrained, you can definitely get away with a game per partition, and state changes far less frequently. Agreed there will be a lot of shared pieces but at least for the stuff covered in this video I think most of it is probably less relevant.
For a game. Can we partition by game_id and not regions. If I understand correctly, you are saying that all games for a region are handled by the same server. But if we shard by game_id, we can have specific instances of the game being handled by specific game servers. And if all the users connect to the same game server then we don't have the issue of write conflicts. What will be the pro/cons of the above approach compared to your approach?
Yes - we're absolutely sharding by game id, this was being done under the assumption that within a game id we'd have too much load to put that on one server and might have to shard further.
@@jordanhasnolife5163 I see thanks for explaining. In system design the thing is in some of the designs I haven't designed something like that so sometimes the scale doesn't seem obvious. So basically the games can be so intense that even on a single server we need the region servers. So kind of you have a hierarchical structure on game_id -> region_id.
Hi Jordan, regarding partitioning the game server. Instead of region, can we use game id as partition key, In this way all the players for a particular game will go the same server
Wouldn't the multipartition lock strategy introduce a lot of latency if too many players are cross-region? Or maybe I'm misunderstanding what the lock is key'd on specifically
So cross region in this case means on the other side of the game map, not like I'm in america you're in asia. Ideally, all "region servers" will be colocated in the same data center, and so will the lock. It definitely does introduce latency, but the hope is that we don't come across these types of writes too often.
Jordan, I am confused, if we already have servers based on region why even make a game with multiple regions cant we restrict the gameplay based on region itself like eg: asia region players will play amongst themselves, and so and so (I think valorant executes this)
PS love your grind, I really appreciate your efforts and although clout works fc it, its shallow and has hardly a good ending PS also your audio and ur camera video is not in sync
Just to clarify this as I was also a little confused but understood after, when Jordan talks about "regions" and splitting them up into different game servers to reduce load, he is not talking about matchmaking and where users are in the world. He is talking about the actual in-game map and splitting that map up into different regions. For Battle Royale games, the maps are ridiculously large and not everything in the game map needs to be accessible to every single player (just the things closest to them). By splitting the game map up into different regions and then partitioning the game servers by the different regions in the game map, you can reduce the load pretty significantly. He then talks about how edge cases where now at certain parts of the map where regions collide, users will have to be able to read/write across partitions where he talks about LB and distributed locks to help with these cases.
This was an awesome video Jordan, thank you. I finally have a video I can send to my friends when they ask me to "just make a mmo game" and be rich
youll be giving them instructions like in a "fuck all" manner?
As one does
Just use unreal, this is a solved problem
@@sid6576 u can configure something u make to be more better, just like u use udp for faster speed although tcp is so cool
This escalated too quickly
You sound like my therapist
😂😂😂😂😂@@jordanhasnolife5163
😂😂@@jordanhasnolife5163
Great video! In a similar theme it would be great to see a Multiplayer Matchmaking Service design.
Hey Jordan, your videos are really good. I have a system design interview coming up. I am really learning a lot from your videos. Thanks a lot.
Thank you Jordan I am a new grad, but I got hooked on your videos because of your jokes. Hehe I’m pretty sure I’m learning system design through laughter. i guess i would be first senior new grad engineer :D
You got it 🥳
My boy never misses an opportunity to push something to Kafka. Noice.
Lmfao
They say I'm a big fan of spilling my data to disk
Hey Jordan, thank you very much for your hard work. Do you mind doing a little clarification on where the load balancer is in the final diargam? Is it a part of the Master Server? Somehow I follow the whole idea until the final roadmap where I got completely confused.
The master server basically caches the zookeeper nodes which tell it which servers are responsible for which regions of the game map, and returns their address to the user accordingly. If the user is close to out of bounds in that region server, it can reach back out to the master server to get the address of the adjacent region server.
Hi, Jordan, really appreciate the content, will you consider sharing your notes in as in format, with a huge asterisk that they can be wrong. It's just that I have a couple of interviews this month and want to revise all the designs but going through the all the older videos is time consuming.
Since you are partitioning the game servers by regions (say 4 regions per game on an average), that would mean that if there are a million games running concurrently, then the system would need 4 million partitions!
Am I correct in my understanding? And if yes, then will all these partitions be separate physical machines or VMs?
You are correct in terms of the number of partitions, but it is not the case that each partition needs to be a separate physical machine. Partitions are just units of work, and can be distributed as necessary (or perhaps not necessary).
played PUBG many times but never thought of building one of it lol. One quick question on dynamic partition, this sounds similar to most of the other dynamic partition (monitor load with heartbeat, prepare replica, build all connection, move some clients' connection), anything special for this case? is R1a and R1b share the same region map (or they are splitting)?
I think the process you described makes a lot of sense in this particular case!
Hey Jordan, I really like your videos! They are super helpful for learning system design, as a junior I learned a lot from your videos. Also wondering if it is possible to see a design about meeting scheduler, a friend of mine meet this question during her interview, she is not sure about the database design. Curious to see a Jordan solution!
For sure, I do have plans to eventually make a Google calendar type of video. Thanks!
Jordan has yes life
Unclear
It would be great to explore how this system can be adapted for other games like Chess. While many components may remain similar, the constraint of write conflicts, storing game state may not be applicable to Chess.
I actually think chess is much easier. Game state is super constrained, you can definitely get away with a game per partition, and state changes far less frequently. Agreed there will be a lot of shared pieces but at least for the stuff covered in this video I think most of it is probably less relevant.
For a game. Can we partition by game_id and not regions. If I understand correctly, you are saying that all games for a region are handled by the same server. But if we shard by game_id, we can have specific instances of the game being handled by specific game servers. And if all the users connect to the same game server then we don't have the issue of write conflicts. What will be the pro/cons of the above approach compared to your approach?
Yes - we're absolutely sharding by game id, this was being done under the assumption that within a game id we'd have too much load to put that on one server and might have to shard further.
@@jordanhasnolife5163 I see thanks for explaining. In system design the thing is in some of the designs I haven't designed something like that so sometimes the scale doesn't seem obvious. So basically the games can be so intense that even on a single server we need the region servers. So kind of you have a hierarchical structure on game_id -> region_id.
@@ChillWithAbhishek Yep!
Its funny that this game state design shares a lot of similarities with building orderbooks in hft hehe
Hi Jordan, regarding partitioning the game server. Instead of region, can we use game id as partition key, In this way all the players for a particular game will go the same server
Yeah, that might not be enough though. This is if you have to partition within a game.
Wouldn't the multipartition lock strategy introduce a lot of latency if too many players are cross-region? Or maybe I'm misunderstanding what the lock is key'd on specifically
So cross region in this case means on the other side of the game map, not like I'm in america you're in asia.
Ideally, all "region servers" will be colocated in the same data center, and so will the lock. It definitely does introduce latency, but the hope is that we don't come across these types of writes too often.
I don't think you can call it the "master" server anymore. I think it's called the "Jordan" server now.
That's the baiting server
Subscribed after realizing you are the rizzlord
Hi Jordan. Nice video, appreciate it. Though I didn't get the point of having master server in front of region servers. Can you clarify please?
Its basically the load balancer
@@jordanhasnolife5163 Thanks
Jordan, I am confused, if we already have servers based on region why even make a game with multiple regions cant we restrict the gameplay based on region itself like eg: asia region players will play amongst themselves, and so and so (I think valorant executes this)
PS love your grind, I really appreciate your efforts and although clout works fc it, its shallow and has hardly a good ending
PS also your audio and ur camera video is not in sync
Just to clarify this as I was also a little confused but understood after, when Jordan talks about "regions" and splitting them up into different game servers to reduce load, he is not talking about matchmaking and where users are in the world. He is talking about the actual in-game map and splitting that map up into different regions. For Battle Royale games, the maps are ridiculously large and not everything in the game map needs to be accessible to every single player (just the things closest to them). By splitting the game map up into different regions and then partitioning the game servers by the different regions in the game map, you can reduce the load pretty significantly. He then talks about how edge cases where now at certain parts of the map where regions collide, users will have to be able to read/write across partitions where he talks about LB and distributed locks to help with these cases.
@itsaugbog is correct, we aren't sharding the world, we're sharding the actual video game terrain. My audio and video are never gonna be in sync :(
@@itsaugbog thanks for the explanation
hey jordan, please update notes on gdrive, you havent shared latest video slides there
You are correct, will do this all in batch in 1-2 months.
@@jordanhasnolife5163 please try to do it asap, I need them for revision
@@jordanhasnolife5163 please try to do it asap, I revise from these notes only