Redis : Database, cache, pub/sub and more at Jelly button games

Preview:

Citation preview

● Jelly Button Games - Introduction

● Pirate Kings - Growth Challenges

● Redis Use Cases

● Summary

Spin the wheel to earn cash and build your island. Attack and steal from your friends, But beware they can take revenge!

Pirate Kings

● Soft launch in Israel and Sweden

● Featured in Google Play Asia

● Game grew virally from 100K to 3.5M in 3 months

● 2M Daily Active Users in 10 days

○ 1M requests per minute

● “Always online” players

● Social network with interactions

● Near real-time

○ No lazy dumps

Pirate Kings

- Our “Swiss Army Knife”

- Using ServiceStack’s Redis client

- Efficient

- Running on RedisLabs

● 100GB DB’s

● Clustered DB’s have 5 shards each (multi-AZ)

● At least 8 CPUs per instance

● Latency: 0.1 msec (avg)

● Network usage: 80k-90k packets/second

Redis

● Cache

● Leaderboard

● Persistent DB

● Pub/Sub

● Time Sync

● 13M keys

● 2,500 concurrent connections

● 20K ops/sec

● Average latency of 0.06ms

● A leaderboard is a SortedSet

● Global / Per Country Leaderboard

● Complexity: O(log(n))

● Logging malicious users’ IPs

(INC with TTL)

● Identifying social relations

(Set)

● Cash King super-fast calculation

(SortedSet)

● Beware: Unbounded growth

● Instant player updates

● Configuration changes

● Time syncing issue between

AWS servers

● Used Redis as “Central Time”

● Avoid using as a solution for

time sensitive features

● Jelly Button Games - Introduction

● Pirate Kings - Growth Challenges

● Redis Use Cases

Nir Shney-dornir@Jellybtn.com

Recommended