Browser strategy game server architecture (with pics)

[johndoebr]

Hi all,

I have been working as a Java Developer for over 7 years and while studying AngularJS I decided to create a browser strategy game for fun, like Travian/TribalWars/Ikariam etc...

Right now I am thinking about how the server architecture should be. I tried to find some examples on how this kind of games distributed their servers but I couldn't find any useful resource, so I came with my own.

My sketch and authentication flow (follow the numbers from 1 to 9):

 

In a general way, is that a suitable one?

From my personal developer experience I decided it was a safe idea to split the public front-end from ther auth and game servers.

Do you think there are any Cons in this architecture?
 

About hosting, which service/host is most suitable for each server?

1) Authentication server, single point
2) Front-End server, distributed over the world
3) Game Servers, each one in its specific country

 

I am open to new ideas and changes!

Thanks in advance!

[mattstyles]

Looks like a good architecture to me.

You might want to think about adding a CDN for globally available static assets to save some load on your game servers but otherwise looks like that setup would be great for large games with a large player base.

As they are all decoupled processes scaling horizontally should let you get up to very very large numbers without too much work.

Welcome to the forums, we get these sort of architectural questions fairly regularly so hopefully you'll come back with some feedback on how it goes for you. I agree, finding people writing about architecture is pretty rare, or, very hard to follow, they often focus on the practical and don't explain why some features of their architecture exist.

[Gio]

Looks very sensible, however if you're serious about this (and it looks like you are because that's a fairly expensive architecture to start with), you may want to add a couple of pieces that are not visible in the picture above, although you may have thought of them already:

• an analytics db (presumably centralized, in the same location as the auth db)
• db backups - it may be a good idea to have these in some geo-redundant cloud storage such as S3
• depending on how replication works for your database of choice, each "WN DB" machine could (should?) actually be multiple machines in the same geographical location but in different availability zones (sorry that's an aws-specific term, not sure what it's called on other infrastructures)

[prvi_treti]

Isn't this overengineering for a Travian like game? (which doesn't have a quick pace, nothing demanding in latency) It can start with a centralized server architecture anyway imo

[johndoebr]

Thank you for all replies. 

I received a suggestion related to #5 and #6 steps, so I postpone and invert the token validation.
Also for clarification sake, #1 and #2 steps don't happen every Client request, it's a "heartbeat" feature, that checks periodically which servers are available and make it ready when a Client asks for it.

This is the updated sketch flow:

 

 

About CDN, yes, i will need it. But I have little to no knowledge about hosting, the CDN distributed server could be my own "Front-end" server? As right now they would be mostly static HTML with a login / server list screen.
Which hosting out there could provide me a nice bandwidth quota for this purpose?

About analytics, I still didn't think about that, but probably I will make use of it in the future. It seems a nice suggestion staying inside auth db, my World Servers could send it periodically through Messaging (I think it would be ApacheMQ in my current scenario).

About backup db, as i said before, for not having knowledge about hosting services, if I host at OpenShift, there is a chance to lose all my DB? I mean, wouldn't they make a catastrophe recovery for me?
I don't see the need to cloud my World Server and its DB for performance purpose as the World Server will be located in a specific geographical location (i.e. US West, US East, South America, West Europe, etc), it's expected the players will choose the World Server which is near to him.

About overengineering, yes, someone had told me that before, I think it might be really over, but I don't know how the current browser games work, so I tried to do my best regarding my developer knowledge. Initially, I might put some applications in the same server to save some money and reduce the "over", but anyway I split as "Front", "Auth" and "Worlds" as being different applications, so I could have some flexibility to choose where I will deploy each one.

Yet, I still don't know how real world scenarios work. Talking for a Travian game, how much is too much?
I made some research on a few Java hosting services, with a JBoss + 512ram + 1gb hdd machine, I would spend about $20~30/month per server, is it reasonable?
And for a distributed Front-end (and possible CDN) server, how much is a good price?

I can only be sure if my server will hold it all once i start some stress tests, until that I am mostly blind for the lack of experience.

 

Thanks in advance!

[mattstyles]

There's no reason you can't start with this all happening on one box, only scale it out when necessary, so long as you dont have anything rely on local instances then you're good to move sections around as an when you need to. DB's can be a little tricky to handle sometimes like this, depends on the DB, whether it can handle multiple instances or prefers to be monolithic. (SQL, for example, prefers to be monolithic but I'm pretty sure there are ways to make it more manageable, I dont use it so cant really inform).

Regarding CDN, I've briefly used Cloudfront a while back, I wasn't in charge of configuring it but theoretically its fairly simple, the provider normally transparently handles bouncing your content out, I think we had it set up to pull from an s3 bucket and distribute to 6 or so centres. Only issue we had was potentially stale content but that was only due to the nature of the application (it could be many minutes between the last request for content and the next so stale content was problematic), it isn't normally an issue.

$20-30 isn't great for 512 ram (its not terrible either), sounds like most of that cash is in the 1gb of storage. I'd guess that most of your world/game servers would require more memory than that as you start getting players hitting it, dunno, you're right, stress tests etc are your best bet. Go cheap as possible to start with and build up as your app develops.

For whats it worth I've set up a number of small apps very very similar to your diagram, nginx serves the front-end, there's a specific process for auth (not always required), and another process (or cluster) for non-client logic.