We'd need to know a lot more (on average – there will of course be a distribution):
- How many seconds per action?
- How many actions per player per match?
- how many players per match?
- How many matches per day per player?
- How much data per action?
- How much data for a “deck setup"?
- How many deck setups per player?
- How much deck management between turns?
- How many days per week does a player play?
I'm going to make some assumptions:
- 4 seconds per action
- 50 actions per match
- average of 3 players per match (matches are 2 or 6 players, with 2 player matches more common)
- 5 matches per day per player
- 1 KB of data per action
- 1 KB of data for a deck
- 10 deck setups per player.
- 10 deck management transactions per day per player, each of which is 1 KB
- A player plays 2 days out of the week
I'm going to assume that cards are picked from a limited set (e g, there are many instances of something like 300 different cards, not each-card-is-unique.) Cards can thus be identified with a simple card ID, and a deck is a list of card IDs, and card art, game binaries, game website, and other such data are not part of this estimate, but instead served by some CDN.
Let's assume some kind of session steered in-memory representation for games (maybe a websocket connection.) Let's assume only game outcomes and deck management transactions go to a database.
Now we can derive some numbers:
- average match duration:
3 players * 4 seconds * 50 actions per match == 600 seconds, 10 minutes/match - average match bandwidth used:
3 players * 50 actions * 1 KB * 3 players (because each player sees each player) == 450 KB/match, plus player/deck setup, so call it 500 KB even. - average matches per day:
1000000 players / 3 players per match * 5 matches / day / player == 1666667 matches/day - number of database transactions:
3 players/match * 1666667 matches + 10 deckmanagement * 1000000 players / day == 15000000 txns/day - overall bandwidth per day:
500 KB/match * 1666667 matches/day + 1 kB/deck * 10 deck/day * 1000000 players / day ~= 850000000 KB/day - overall database storage:
7 days / week / 2 days / player * 1000000 players / day * 10 decks/player * 1 KB/deck == 35000000 KB storage - average number of concurrent matches:
1666667 matches / day * 600 seconds / match / 86400 seconds / day == 11574 matches
If you can jam 1000 matches into a m6g.2xlarge EC2 instance, you'll need 12 of them for average, but peak/off-peak can easily be a factor 2, so call it 24 of them. They're 30 cents an hour, so $173/day in server cost, plus a small amount of money for the EBS boot volumes, call it $200/day total. Less if you spin down instances when they're not needed. You'll very likely also need instances for matchmaking and general website and development/testing and so on, don't forget!
Data lives in a database. 15M txns/day is 174 txns/s, which with a 2x peak would be 350 txns/sec. This could be somewhat high, depending on how big each txn is. Let's call it a db.r6g.4xlarge Aurora instance. Those are about $3/hour, plus some small charges for storage of backups and such, call it $100/day tops. 35 GB of data is no big deal for such a database. But DO benchmark the transaction throughput – I think it would be fine, but only real workloads can prove it out. If you hit a ceiling, you may have to shard things. Also, if you want the ability to instant fail-over in case of failure, you'll need to run a second (and maybe third) copy in another AZ in the same region, which doubles/triples the cost.
OK, so, bandwidth. Again – all of the card/game artwork and static site content and javascript apps and downloads (if any) and so on go into a CDN, and are not counted. Just for game transactions, 850 GB/day, or about 26 TB/month, will run you about $75/day. (AWS bandwidth is expensive, but quite high quality.)
Finally, you'll probably put this all behind an NLB service, rather than putting your servers straight on the internet. You'll use about 35 NCLU/hour (their measurement unit, which for you is determined by GB/hour) will cost you about $5/day. ALB and ELB services cost more and scale worse, so I recommend against those.
All in all, with the above assumptions, your utility bill will be (200+100+75+5) or about $400/day.
As you can see, there are a lot of assumptions here. Will you fit 1000 games per instance? Will games have the given network characteristics? Will you be able to offload static content to CDNs? What will the actual database load be? Is there a second layer of crossbar traffic you need to build, possibly doubling the number of servers? Will you apply sharding to databases? Will you try to build this on Lambda, or container services, or maybe an elastic kubernetes cluster? Only you can know for sure!
Edit: Apparently, using more than one dollar sign in the same paragraph will screw up whitespace and duplicate text within the paragraph in this forum editor. I'm hoping this doesn't mean the site is vulnerable to XSS or injection attacks… I wrapped fixed-red quotes around them, hoping that will fix it.
