Tabtale story: Building a publishing and monitoring mobile games architecture with high scale

1,135 views
1,007 views

Published on

At Tabtale we are setting up an entire server side for the all the publishing services. These services include dynamic game configurations, error collection, analytics, social services and more.Tabtale is among the world’s top app publishers with millions of downloads so we are putting a great deal of effort in creating an extremely highly scalable and fault tolerant architecture. In this talk I will go over the architecture decisions taken to support the scalability and diversity that is required from the server side services while keeping the management of this infrastructure sane.
~30min By Assaf Gannon

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,135
On SlideShare
0
From Embeds
0
Number of Embeds
646
Actions
Shares
0
Downloads
5
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Tabtale story: Building a publishing and monitoring mobile games architecture with high scale

  1. 1. TabTale story: Building a publishing and monitoring mobile games architecture with high scale Assaf Gannon FullStack Developers Israel 20.5.2014 Google Campus TLV Hosted by:
  2. 2. Assaf Gannon
  3. 3. The project’s goal: Provide a set of server side services and SDK for the company’s apps
  4. 4. Mobile Device Client App SDK Server First Sketch
  5. 5. TabTale is a very successful startup that develops interactive books, games, and educational apps • Released Over 250 apps for children on both iOS and Android devices • Over 350 million downloads • Over 25M active monthly users text
  6. 6. The Tricky Stuff text
  7. 7. Zero downtime Clients must never be affected from server failures or downtime text
  8. 8. Zero Downtime - Solutiontext Solid Infrastructure - AWS ● Elastic Beanstalk - PaaS to run the services ● S3 - static content storage and delivery service ● MongoHQ - Managed MongoDB ● RedisLab - Managed Redis
  9. 9. Zero Downtime - Solution • A good contingency: ○ Fallback to static content on S3 text
  10. 10. Large Scale from Day 1text
  11. 11. Large Scale from Day 1 • Horizontal Scaling - Stateless servers • Prevent heavy server loads ○ Setup multiple tiers of static content delivery: ■ CDN (Cloud Front) ■ S3 ■ Nginx / Apache ■ Pre-generated permutations on Redis / in memory • Use cache effectively text
  12. 12. Effective Cachetext
  13. 13. Effective Cache, cont.text
  14. 14. Rapidly Changing Requirements • Avoid Monolithic Application • Take the “Micro Services” approach from the beginning • Dynamic Model - loose types • Separate Data Base per Service • Services are entirely stateless • Services are decoupled, and talk JSON text
  15. 15. Node js Ideal for rapid development of IO intensive applications ● Extremely easy and fast to setup, develop, and deploy ● Very low learning curve ● Speaks JSON as mother tongue ● Great performance doin IO operations ● NPM ● Can be deployed to multiple PaaS providers including Elastic Beanstalk text
  16. 16. Nodejs Internal Overviewtext
  17. 17. The Event Looptext
  18. 18. Spring Boot The Java way to rapidly bootstrap applications ● Create stand-alone Spring applications ● Embed Tomcat or Jetty directly (no need to deploy WAR files) ● Provide opinionated 'starter' POMs to simplify your Maven configuration ● Automatically configure Spring whenever possible ● Provide production-ready features such as metrics, health checks and externalized configuration ● Absolutely no code generation and no requirement for XML configuration text
  19. 19. MongoDB Great for managing document oriented data and Meta Data ● No schema management ● Very fast reads ● Very simple and powerful DSL text
  20. 20. Tricky Stuff Checklist • Zero downtime • Large scales from day 1 • Vague and rapidly changing requirements text
  21. 21. THANK YOU Assaf Gannon Email: assaf@tikalk.com

×