Social PlatformsWhat goes on under the hood

Manish Pandit

Silicon Valley Code Camp 2010

Agenda

• Components of Social Platform• Challenges• Technology• API• Engineering Process

Components

• User Profile• Relationships• Activity Streams

Components::User Profile

• Basic user information• Extended information based on the context– Player Cards

• Bragging rights – Points, levels– Achievements, badges

• Activities

Components::Relationships

• Friending– Unidirectional (the Twitter model)– Bidirectional (the Facebok model)

• Association– Comments– Ratings, Thumbs– Bookmarking/favoriting

• Recommendations

Components::Activity Streams

• Who is doing what and when• All about Actors, Actions, Objects and Targets• Activitystrea.ms standard vs. OpenSocial• Commentable

Challenges

• Authentication• Performance– ActivityStrems

• Integration• Flexibility• Testing

Challenges::Authentication

• People are tired of creating accounts on every site

• Need to support existing login method if the platform caters to an existing audience– Existing auth may not work well with Open API

initiatives• Open API and Oauth– 2 legged: Service to Service– 3 legged: User to App to Service

Challenges::Performance

• Identify the bottlenecks • Measure everything• Use CDNs for all static content• Front end optimization via async loading• Database optimization via indexes, sharding• Caching • Scaling the sorts• Scaling up vs. Scaling out

– CAP theorem– Relational vs. NOSQL storage– Read vs. Write heaviness

Challenges::ActivityStreams

• Query vs. Propagation– Queries are read heavy– Propagation is write heavy– Deletion is a pain with propagation

• Activity Aggregation– Aggregation on actor vs. object

• Normalized vs. Denormalized storage– Comments

• Decorating the activities on each request

Challenges::Integration

• Integration with legacy touchpoints • Opening up the API– More channels like Mobile– More independent applications

• Rate limiting and access control• Don’t forget existing data– Data outlives code

Challenges::Flexibility

• Flexibility in the code to adapt changing requirements quickly and seamlessly– Good design– DRY SOCs

• Flexibility in the infrastructure to adapt changing traffic and behavior– Virtualization– Heavy replication

• Flexibility in the team to respond to changes– Process

Challenges::Testing

• Automated Testing wherever possible• Developer Focus on test coverage (80+%)• Continuous Integration and Deployment– Cucumber + Hudson

• Cross browser testing (yes, including IE)

Technology

•Java •RubyServices•MemcachedCaching•MySQL•MongoDB (and Voldemort for a while)Persistence

•RabbitMQMessaging

Technology:: Services

• Java services– Tomcat with Shindig 1.1, 4 nodes– REST/JSON

• Ruby – Rails Admin App for moderation and points/levels– Migration Scripts– Twitter bot for routing #myign tweets to the platform– Misc. scripts to invalidate memache keys and test

service endpoints

Technology::Caching

• Memcached – Extremely trivial to set up and maintain– Almost never dies– Massive scale out– Careful with• Cache hotspots• Concurrent writes• On the fly scale-out• Key/Value size limits

Technology::Persistence::MySQL

• MySQL– Proven, cheap to develop and operate– Maslow’s hammer– Easy scale out– Hard to store (and retrieve) network graphs– Write scaling with single master– Not the best choice for activitystreams– Schema changes lock the table(s)

Technology::Persistence::MongoDB

– Awesome write scaling• Great for activity propagation model

– In place updates• Using $push and $set

– Excellent for storing social relationships as documents

– Very easy to cluster• We are running replica pairs, plan to move to replica sets

– Schema-less• No need to run alter scripts on 18M-row table

Technology::Persistence::MongoDB

• Queryable– Rich Query language ($in, $size, $exists, $slice)– MapReduce for heavy data crunching

• Supports Indexing– You can even index collections inside a document

• Storage – ~4x storage compared to relational data

• Emerging technology– Index defragmentation – $or and indexing (to be supported in 1.7)– Load balancing support in the driver (coming soon)

Technology::Messaging

• RabbitMQ for messaging– Ease of clustering– Written in Erlang for high performance and

availability– Used for• Propagation of activities• Sending out email alerts• Indexing data in Solr

API

• Person– GET @self, @friends, @followers, @all, PUT/POST @self, @friends

• Activities– GET @global, @self, @friends, POST @self

• MediaItems– GET @self, @all and POST @self

• AppData– For applications to store/retrieve data as key-value pairs GET/POST

@self• Status

– GET @friends, @self, @followers , POST @self

Monitoring::Newrelic

• Must have for any Java/Ruby webapp• Monitoring and troubleshooting• Save a ton of $ and time by efficient root

cause analysis tools• Agents for Ruby and Java– IGN Engineers helped write PHP and Memcached

agents

Engineering Process

• Social Applications and community– Check the pulse of the community

• UserVoice (http://ign.uservoice.com)

– Less is more– Distinguish yourself and focus on your niche

• Be Agile - Release early, release often– Do not shock your audience– Announce the changes/features on a blog

• Eat your own dog food– http://people.ign.com/ign-labs

Lets talk numbers

• Released July 2010 as beta• Daily API requests ~25M• Daily page views ~30K• Daily Uniques ~12K• 6ms response times• Expected traffic 8-10x with more integration

and mobile platform

About.me

Manish PanditEngineering Manager, Social Platform at IGN

Email: pandit.manish-at-gmail.comTwitter: @lobster1234LinkedIn: http://www.linkedin.com/in/mpanditBlog: http://contrarianwisdom.blogspot.comMyIGN: http://people.ign.com/mpanditign

We’re hiring!

• http://corp.ign.com • http://labs.ign.com• http://my.ign.com• http://people.ign.com/ign-labs