The presentation will be deep dive into how to build scalable social web apps on Windows Azure IAAS by utilizing latest technologies based on document based storage

1. Band of Brothers, building scalable social
web apps on Windows Azure
with ASP.NET MVC3, MongoDB, RabbitMQ
Marjan Nikolovski
Co-Owner, Senior Software Engineer at EmitKnowledge
Senior Software Engineer at Seavus
Contact:
emitknowledge.com/@mnikolovski
marjan@emitknowledge.com

2. Agenda
• Social web architecture
• Intro to MongoDB
• Data modeling for MongoDB
• Intro to RabbitMQ
• Preparing your guns for pub/sub with RabbitMQ
• Data painting with MVC3
• Hosting and scaling strategies on Windows Azure

3. Social web architecture
• By definition a social web must provide connectivity between
the users for a common good
• From functional aspect a social web must provide:
• Connectivity (Relationships)
• Privacy
• Private messaging
• Notifications and events (both real-time and offline)
• Recommendations

4. Social web architecture
• Connectivity, how users are socializing
• Directional or bidirectional relations ?
• How are users going to socialize ?
• Post Sharing
• Groups
• Private messaging
• Gamification

5. Social web architecture
• Privacy
• Beware of details
• Who, When and What
UserA User B User C
Who can access my
Y N
data ?
When can my data be
After publish Delay with 1 day
accessed ?
What kind of data could
Posts and events Posts
be accessed ?

6. Social web architecture
• Private messaging aka Conversations
• Define messaging types:
• One to One
• Group messaging
• Define messaging strategy
• When a new conversation starts ?
• Until when does it last ?
• Spam detection and prevention
• Mark as spam strategy
• Spam filtering strategy
• Both ?

7. Social web architecture
• Notifications and events (both real-time and offline)
• When to notify ?
• Frequency of notifications
• To stream or to aggregate?
• To filter or display all ?

8. Social web architecture
• Recommendations
• Define recommendation method:
• Friends method
• Recommends the friends of my friends
• Ease to implement
• Big miss factor
• Recommends people that we possibly know
• Not very practical
• Sharing interests method
• Recommend me a friend that we have a starting point to talk about
• Efficient for connectivity
• Needs initial user input for building the analytics

9. Social web architecture
• From technical aspect must respect:
• Stateless
• Pluggability
• Async execution
• Load distribution
• Intensive logging and auditing
• Content delivery strategy

10. Social web architecture
• Stateless
• Azure instance load balancing is your enemy
• We don’t know on which instance the request will end (cloud load
balancing)
• So, forget about using server side session or tempdata
• Yes we can store it in DB, but performance per request ?

11. Social web architecture
mysocialapp.cloudapp.net
mysocialapp.cloudapp.net

12. Social web architecture
• Pluggability
• Enable the platform to go down partially
• Develop your functionalities as plugins
• Enable real-time plugin load/unload (hotplug)
• Partial deployment

13. Social web architecture

14. Social web architecture
• Async execution
• Sequential processing only at the minimum, everything else
delegate to background services
• User registration use case
• User reset password use case
• User notification use case
• Time and data intensive operations must execute as background
services jobs

15. Social web architecture
Web server Messaging infrastructure Worker services
Send create user request Send confirmation email message
User created response Notify for new user registration message

16. Social web architecture
• Load distribution
• We hit the processing limit per machine. Now what ?
• Develop your data and time intensive functionalities with job
distribution in mind
• Event based Producer – consumer jobs
• Each functionality requires
• Job orchestrator
• Job processor

17. Social web architecture
Notify from 1 – 100
Notify from 101 – 123
Notify all of my friends
Notify all of my friends Notify from 1 – 100
New user post MESSAGING INFRASTRUCTURE
Notify from 101 – 123

18. Social web architecture
• Intensive logging and auditing
• You will always want to know what your users are up to
• Analytics can’t help !
• Put your intensive logging and auditing so you can playback later
• Log and audit everything you can get
• Build your own analytics system

19. Social web architecture
{
"Username" : "some_username",
"IsAuthenticated" : false,
"RawUri" : "/Account/Login",
"BaseUri" : "/Account/Login",
"HttpMethod" : "POST",
"IpAddress" : "127.0.0.1",
"Refferer" : "http://localhost:42378/",
"UserAgent" : "mozilla/5.0 (windows nt 6.1) applewebkit/535.12 (khtml, like gecko) maxthon/3.3.4.4000
chrome/18.0.966.0 safari/535.12",
"IsCrawler" : false,
"IsSecureResource" : false,
"Action" :
"Emit.Knowledge.Controllers.RequestLogging.UserRequestLoggingController.VerifyUserCredentials(String
username, String password, User& verifiedUser)",
"Data" : {
"username" : "test333"
},
"IsFaulted" : false,
"CreatedOn" : {
"UtcDateTime" : new Date("3/10/2012 01:40:52")
}
}

20. Social web architecture
• Content delivery strategy
• Reference your scripts with build number
• .js?ver=1.0.1 to propagate script changes with ease
• Minify as many js scripts into one
• Group page images into sprites and add build number
• .png?ver=1.0.1
• Reference user images to the CDN
• Analyze the average change of user profile image to determine
the image caching period

21. Intro to MongoDB
• Document store
• Fast, scalable and available
• JSon – used for data hydratation
• Dynamic
• Stores data structured as documents instead of row as seen in
RDBMS
• Uses Query, Insert, Update and Remove for data manipulation
• Used for adding data at high rates without “choking” the system

22. Intro to MongoDB
• Documents in MongoDB
• Each document can be of size max to 16mb
• Each document you insert into MongoDB will be assigned an id
consisted of:
• This is a 12-byte value consisting of 4 parts:
timestamp (4 bytes)
• machine identifier (3 bytes)
• process id (2 bytes)
• increment (3 bytes)
• in MongoDB, each document will contain not only the values, but the
key names (~"column names" in relational db-speak) too. So if you
have keys: “Username" and “Password", then those alone will add 16
bytes to each document.
• MongoDB automatically adds some padding to the documents to
allow for documents to grow in size to try and reduce the need for
documents to be moved around if they do grow

23. Data modeling for MongoDB
• Forget what you’ve learned at school and shift your mind
• Want to be fast ? – Denormalize data that will be static
(IAuditable – ring any bells ?)
• Common pitfalls
• To render a post we need the post content and the username
• Modeling by the book will get you to model the Content entity to
have Title, Content, UserId
• Now we need to fire two queries to display the username

24. Data modeling for MongoDB
• Beware of your queries
• Analyze all of your queries
• Set index per query
• But don’t forget the order by in the index 
• Mongodb has limitation for “OR” queries and sorts (indexing will
not help you here)
• Think in map/reduce way maybe ?

25. Intro to RabbitMQ
• Robust and reliable messaging for apps
• Supports many messaging patterns
• Publish-subscribe
• Topic based PubSub
• Point-to-point
• Request-reply
• Store and forward
• …

26. { Publish-subscribe
Publisher
Publish an event
Topic
Consumes the event Consumes the event
Subscriber Subscriber

27. { Topic based PubSub
Topic
Consumes the event Consumes the event
Subscriber Subscriber
Consumes the event
Subscriber
Subtopic
Publish an event
Publisher

28. { Point-to-point
Publisher Queue Subscriber

29. { Request-reply
Subscriber
Publisher/Subscriber Topic Subscriber
Subscriber

30. { Store and forward
Subscriber
Publisher/Subscriber Topic Subscriber
Subscriber
Data

31. Preparing your guns for pub/sub with RabbitMQ
• Establishing pub/sub architecture
• Who will listen on what ?
• Do we need to intercept messages ?
• Do we need to deliver one message to many subscribers ?
• Do we need to distribute the message processing ?
• Two levels of messaging
• Job coordination and distribution
• Server instancing coordination
• Messaging patterns of interests
• Pub/Sub
• Topic based Pub/Sub

32. Preparing your guns for pub/sub pub/sub with
RabbitMQ
• Persist messages that must be delivered, everything else just
flush it through the wire
• Topic subscription is your enemy
• Don’t expand your topics tree in depth
• Minimize topic root subscriptions

33. Data painting with MVC3
• Delegate data render to the client with dynamic data instead
on server side
• Prepare your static content and the templates in the views
(this will help you to reduce the traffic. Dom will be created on
fly.)
• Knockout your dynamic data

34. Data painting with MVC3
<script id="notes-template" type="text/html">
{{each notes }}
<div class="note-wrap">
<div class="note-title">
<div class="title-text">${GetTitle}</div>
<div class="title-date">${LastEditedDate}</div>
</div>
</div>
</div>
{{/each}}
</script>

35. Data painting with MVC3
<div class="note-wrap">
<div class="note-title">
<div class="title-text">Title 1</div>
<div class="title-date">2012-01-01</div>
</div>
<div class="note-title">
<div class="title-text">Title 2</div>
<div class="title-date">2012-01-02</div>
</div>
<div class="note-title">
<div class="title-text">Title 3</div>
<div class="title-date">2012-01-03</div>
</div>
</div>
</div>

36. Data painting with MVC3
Template + Ajax Server render
638 bytes - JSON /
2246 bytes - HTML template 22460 bytes - HTML
TOTAL 2884 bytes 22460 bytes – HTML

37. Hosting and scaling strategies on Windows Azure
• Design deployment and scaling strategy per component:
• Web server
• Data server
• Messaging server
• Worker server

38. Hosting and scaling strategies on Windows Azure
• When to scale ?
• MongoDB instances
• Indexes are too large to fit in memory
• First scale vertically with RAM then shard
• RabbitMQ instances
• Message delivery slows down
• Scale vertically with CPU then shard
• ASP.NET MVC instances
• Number of users goes large
• Check what is eating the machine throughtput
• Usually problem with the notifications long pooling
• Scale horizontally with more extra small or small instances
• Worker instances
• Job processing time goes “large”
• Scale horizontally with more extra small or small instances
• Round robin processing strategy will help you to relax the job processing

39. Hosting and scaling strategies on Windows Azure
• Two instances per type to meet with the SLA requirements
• Use CentOS for MongoDB, Linux has better memory
fragmentation than Windows
• For RabbitMQ choose the OS that you are most comfortable
with.
• Windows 2K8 OS for the ASP.NET MVC

40. Hosting and scaling strategies on Windows Azure
• Open SSH and MongoDB ports only
• Don’t forget to disable anonymous login on the MongoDB and
set u/p combinations for both server and database

41. Hosting and scaling strategies on Windows Azure
• Open SSH/Remote Desktop ports and RabbitMQ
communication port
• Disable anonymous connections to the instance and add u/p
combinations for connection to the RabbitMQ server