SlideShare a Scribd company logo
1
Scalable Application
Architecture
Common Patterns & Approaches
AHM Pervej Kabir &
ERA-InfoTech Limited
Cell:+8801757051005
2
Presentation Indicator
 1. Introduction for understanding Scalable Apps.
 2. Network Based Architecture
 3. Application Based Architecture
3
Introduction
Scalable Web Architectures?
- What does scalable mean?
- What’s an architecture?
An answer has in next 12 parts.
4
Understanding- 1. Scaling
 What is Scalable?
Scalable means Expandable. Referring to hardware or
software or application that can handle a large increase in
users, workload or transactions without undue strain. Scalability
is a system's ability to process more workload.
 What is scalability not ?
 Raw Speed / Performance
 HA / BCP
 Technology X
 Protocol Y
5
Understanding- 1. Scaling
 Objectives of scalability
 Traffic growth
 Dataset growth
 Maintainability
 Two kinds of scalability:
 Vertical (get bigger)
 Horizontal (get more)
6
Understanding-2.Architecture
Architectures then?
 The way the bits fit together
 What grows where
 The trade-offs between good/fast/cheap
Storage array
Cache
AJAX!!!1
App server DatabaseInternet
7
Understanding-2.Architecture
App servers scale in two ways:
 Really well
 Quite badly
Sessions :
 (State)
 Local sessions == bad

When they move == quite bad
 Centralized sessions == good
 No sessions at all == awesome!
8
Understanding-2.Architecture
Super slim sessions Properties:
 If you need more than the cookie (login status, user id,
username), then pull their account row from the DB
 Or from the account cache
 None of the drawbacks of sessions
 Avoids the overhead of a query per page
 Great for high-volume pages which need little
personalization
 Turns out you can stick quite a lot in a cookie too
 Pack with base64 and it’s easy to delimit fields
9
Understanding-2.Architecture
Apps Server:
10
Understanding-2.Architecture
 Scaling the web app server part is easy
 The rest is the trickier part
 Database
 Serving static content
 Storing static content
 Other services scale similarly to web apps
 That is, horizontally
 The canonical examples:
 Image conversion
 Audio trans coding
 Video trans coding
 Web crawling
 Compute
Hardware Load balance:
 A hardware appliance
 Often a pair with heartbeats for HA
 Expensive!
 But offers high performance
 Many brands
 Alteon, Cisco, Netscalar, Foundry, etc
 L7 - web switches, content switches, etc
11
Understanding-3. Load Balancing
Software Load balance:
 Lots of options
 Pound
 Perlbal
 Apache with mod_proxy
 Wackamole with mod_backhand
12
Understanding-3. Load Balancing
Wakamole
Parallelizable:
 If we can transcode/crawl in parallel, it’s easy
 But think about queuing
 And asynchronous systems
 The web ain’t built for slow things
 But still, a simple problem
13
Understanding-4. Queuing
14
Understanding-4. Queuing
Asynchronous SystemSynchronous System
15
Understanding-5. Relational Data
Databases:
 Unless we’re doing a lot of file serving, the database is the
toughest part to scale
 If we can, best to avoid the issue altogether and just buy bigger
hardware
 Dual Opteron/Intel64 systems with 16+GB of RAM can get you
a long way
Read Power of Apps:
 Web apps typically have a read/write ratio of somewhere
between 80/20 and 90/10
 If we can scale read capacity, we can solve a lot of situations
 Database replication!
16
Understanding-5. Relational Data
17
Understanding-6. Caching
 Caching avoids needing to scale!
 Or makes it cheaper
 Simple stuff
 mod_perl / shared memory

Invalidation is hard
 Database query cache

Bad performance (in most cases)
 Getting more complicated…
 Write-through cache
 Write-back cache
 Sideline cache
18
Understanding-6. Caching
 Getting more complicated…
 Write-through cache
 Write-back cache
 Sideline cache
Write-through Write-back Sideline
19
Understanding- 7.HA Data
 The key to HA is avoiding SPOFs
 Identify
 Eliminate
 Some stuff is hard to solve
 Fix it further down the tree

Dual DCs solves Router/Switch SPOF
20
Understanding-7. HA Data
Master-Master:
 Either hot/warm or hot/hot
 Writes can go to either
 But avoid collisions
 No auto-inc columns for hot/hot

Bad for hot/warm too

Unless you have DB
 But you can’t rely on the ordering!
 Design schema/access to avoid collisions

Hashing users to servers
21
Understanding-7. HA Data
Ring:
 Master-master is just a small ring
 With 2 nodes
 Bigger rings are possible
 But not a mesh!
 Each slave may only have a single master
 Unless you build some kind of manual replication
22
Understanding-7. HA Data
Dual Tree:
 Master-master is good for HA
 But we can’t scale out the reads (or writes!)
 We often need to combine the read scaling with HA
 We can simply combine the two models
23
Understanding-8. Federation
Data Federation:
 At some point, you need more writes
 This is tough
 Each cluster of servers has limited write capacity
 Just add more clusters
 Split up large tables, organized by some primary object
 Usually users
 Put all of a user’s data on one ‘cluster’
 Or shard, or cell
 Have one central cluster for lookups
24
Understanding-8. Federation
Data Federation:
 Need more capacity
 Just add shards!
 Don’t assign to shards based on userid!
 For resource leveling as time goes on, we want to be able to move objects
between shards
 Maybe – not everyone does this
 ‘Lockable’ objects
25
Understanding-8. Federation
Data Federation:
 Need more capacity?
 Just add shards!
 Don’t assign to shards based on userid!
 For resource leveling as time goes on, we want to be able to move objects
between shards
 Maybe – not everyone does this
 ‘Lockable’ objects
26
Understanding-8. Federation
Data Federation:
 Heterogeneous hardware is fine
 Just give a larger/smaller proportion of objects depending on hardware
 Bigger/faster hardware for paying users
 A common approach
 Can also allocate faster app servers via magic cookies at the LB
27
Understanding-8. Federation
Simple things first:
 Vertical partitioning
 Divide tables into sets that never get joined
 Split these sets onto different server clusters
 Logical limits
 When you run out of non-joining groups
 When a single table grows too large
28
Understanding-9. Multi-site
HA
Multiple Data centers:
 Having multiple datacenters is hard
 Not just with one DB
 Hot/warm with DB slaved setup
 But manual (reconfig on failure)
 Hot/hot with master-master
 But dangerous (each site has a SPOF)
 Hot/hot with sync/async manual replication
 But tough (big engineering task)
29
Understanding-10. File Servings
 Serving lots of files is not too tough
 Just buy lots of machines and load balance!
 We’re IO bound – need more spindles!
 But keeping many copies of data in sync is hard
 And sometimes we have other per-request overhead (like
auth.)
Reverse Proxy
30
Understanding-10. File Servings
 Serving out of memory is fast!
 And our caching proxies can have disks too
 Fast or otherwise

More spindles is better

We stay in sync automatically
 We can parallelize it!
 50 cache servers gives us 50 times the serving rate of the origin server
 Assuming the working set is small enough to fit in memory in the cache
cluster
Reverse Proxy
31
Understanding-10. File Servings
Invalidation:
 Dealing with invalidation is tricky
 We can prod the cache servers directly to clear stuff out
 Scales badly – need to clear asset from every server –
doesn’t work well for 100 caches
 We can change the URLs of modified resources
 And let the old ones drop out cache naturally
 Or prod them out, for sensitive data
 Good approach!
 Avoids browser cache staleness
 Hello Akamai (and other CDNs)
32
Understanding-10. File Servings
Perlbal backhanding:
 Perlbal can do redirection magic
 Client sends request to Perbal
 Perlbl plugin verifies user credentials

token, cookies, whatever

tokens avoid data-store access
 Perlbal goes to pick up the file from elsewhere
 Transparent to user
33
Understanding-10. File Servings
Permission URLs:
 If we bake the auth into the URL then it saves the auth step
 We can do the auth on the web app servers when creating HTML
 Just need some magic to translate to paths
 We don’t want paths to be guessable
34
Understanding-11. Storing File
 Storing files is easy!
 Get a big disk
 Get a bigger disk
 Horizontal scaling is the key
 Again
Connecting to storage:
 NFS
 Stateful == Sucks
 Hard mounts vs Soft mounts, INTR
 SMB / CIFS / Samba
 Turn off MSRPC & WINS (NetBOIS NS)
 Stateful but degrades gracefully
 HTTP
 Stateless == Yay!
 Just use Apache
35
Understanding-11. Storing File
Multiple volumes:
 Volumes are limited in total size
 Except (in theory) under ZFS & others
 Sometimes we need multiple volumes for performance reasons
 When using RAID with single/dual parity
 At some point, we need multiple volumes
36
Understanding-11. Storing File
HA Storage:
 HA is important for assets too
 We can back stuff up
 But we tend to want hot redundancy
 RAID is good
 RAID 5 is cheap, RAID 10 is fast
 But whole machines can fail
 So we stick assets on multiple machines
 In this case, we can ignore RAID
 In failure case, we serve from alternative source
 But need to weigh up the rebuild time and effort against the risk
 Store more than 2 copies.
37
Understanding-12. Field work
 Flickr
 Because we know it
 LiveJournal
 Because everyone copies it
38
Understanding-12. Field work
Flickr Architecture:
39
Understanding-12. Field work
LiveJournal Architecture:
40
Network Based Architecture
41
Application Base Architecture
Contain:
1. Why n-tier?
2. Layers.
3. Monolithic or 1-tier architecture.
4. 2-tier architecture.
5. 3-tier architecture.
6. Need of MVC.
7. MVC architecture.
8. MVC components.
9. Comparison between MVC and 3-tier.
42
Application Base Architecture
1. Why n-tier:
Need of e-commerce solutions; increase in users and merchant sites all over the
world.
Applications should be scalable, user-friendly, have tight security and easily
maintainable.
2. Layer:
Layer means logical.
Tier means physical.
Generally there are three layers:-
Presentation
Business
Data access layer
43
Application Base Architecture
Layers Presentation:
Presentation Layer:
involves with client and application interaction. Provides user friendly interface for
the clients.
Business Layer:
contains the application code or the core functionalities of the application or
what the application will perform.
Data access Layer:
involves with the maintaining database and storage of data.
44
Application Base Architecture
3. Monolithic or 1-tier:
1.Presentation layer, Business layer and Data Access layer are tightly connected. As the layers are tightly
connected(depends on each other), if any of the layer code are changed then other layers should be
affected and the codes in other layers need to be changed.
2.Traditional approaches of the applications are based on this type of architecture. Typically implementation
of 1-tier architecture can be a C program running in a computer.
4. 2-tier:
1.In this type of architectures the presentation layer, the business logic layer are separated from the data
access layer.
2.The advantages of this layer is that the code of the data access layer can be changed any time without
affecting the code of the other layer i.e. the whole database and the layer can be changed anytime.
3.The database(i.e. the data access layer) can be present anywhere around but the other two layers should
be together(tightly connected).
4.As the presentation and the business logic are still connected they should be present at the client side to
work together; due to the concentration of the client this type of client is called thick client.
5.Problems faced by this type of architecture is the client should always get the updated copies of the
application if there is a change in the application codes or application developer modifies the application.
6.The application developer may not want to give the code to the relatively third parities even if the code is
pre compiled
45
Application Base Architecture
2-Tire Architected:
46
Application Base Architecture
5. 3-tier:
1.In this type of architecture the presentation layer, the business logic layer and the data access layer are
separated from each other and are present on three different tiers therefore they are loosely connected.
2.The main advantages is that any change in the code in one layer will not affect the other layers and the
platform can also be changed independently.
3.Now the web designer can concentrate on the design of the user interface i.e. the presentation logic, the
application developer concentrate on developing the application i.e. the business logic and the database
manager can handle the database independently.
4.Today’s application are based on 3-tier architecture which are scalable, easy to maintain, components are
reusable and faster development
47
Application Base Architecture
6. Need Of MVC Architecture :
Need to access the data from different context such as mobiles, touch screen, desktop, etc.
 Need to show the data in different context such as mobiles, touch screen, desktop, etc.
 Need to show multiple views of the same data such as Thumbnails, List or details.
Need to change the designs without changing the core business logic.
7. MVC Solution:
 Separate the core business logic form the presentation logic.
 Separate views for the same data.
48
Application Base Architecture
MVC Architecture :
49
Application Base Architecture
8. MVC Component:
Model: It contains the core functionalities and the business logic of the application. It accepts the state query
from the model and controller and it provides the updated information to the view component.
View: This component is responsible for the presentation logic and the user interaction between the
application. The model provides different information to different user which can be represented in different
ways. The main work of the view component is to provide the suitable information to the user.
Controller: It accepts the user input through the view component and process them and if any changes are
required then it perform the changes after that it response to the client
9. MVC Vs. 3-tier:
1. In MVC architecture the components communicate directly with each other in order to maintain a coherent
user interaction but in case of 3-tier the presentation layer(front end) communicates with the data access
layer(back end) through the business layer(middleware).
2. In 3-tier the Layers are present on three different tiers or machines where as in MVC the layers are
present on single tier or machines.
50
Scalable Application
Architecture
Thank You

More Related Content

PPT
Building a Scalable Architecture for web apps
PPT
Building Highly Scalable Web Applications
PDF
Scalable web architecture
PPTX
Oracle on AWS partner webinar series
PPT
Vertical vs Horizontal Scaling
PPTX
Advanced data migration techniques for Amazon RDS
PPTX
Disaster Recovery Synapse
PPTX
Azure DBA with IaaS
Building a Scalable Architecture for web apps
Building Highly Scalable Web Applications
Scalable web architecture
Oracle on AWS partner webinar series
Vertical vs Horizontal Scaling
Advanced data migration techniques for Amazon RDS
Disaster Recovery Synapse
Azure DBA with IaaS

What's hot (12)

PPTX
AWS Storage Tiering for Enterprise Workloads
PPTX
Oracle Peoplesoft on AWS: A quick introduction
PPTX
Migrating enterprise workloads to AWS
PPTX
Oracle Solutions on AWS : May 2014
PPTX
Best Practices for running the Oracle Database on EC2 webinar
PDF
Oracle COTS Applications on AWS
PDF
Oracle on aws overview sep 2011
PDF
Introducing Amazon RDS Using Oracle Database
PPTX
AWS Cloud SAA Relational Database presentation
PPTX
Cloud Architecture best practices
PPTX
PDF
Fault Tolerance with Kafka
AWS Storage Tiering for Enterprise Workloads
Oracle Peoplesoft on AWS: A quick introduction
Migrating enterprise workloads to AWS
Oracle Solutions on AWS : May 2014
Best Practices for running the Oracle Database on EC2 webinar
Oracle COTS Applications on AWS
Oracle on aws overview sep 2011
Introducing Amazon RDS Using Oracle Database
AWS Cloud SAA Relational Database presentation
Cloud Architecture best practices
Fault Tolerance with Kafka
Ad

Viewers also liked (13)

PPTX
Building Modern Web Apps with MEAN Stack
PDF
Scalable Angular 2 Application Architecture
PPT
Scalable Web Architecture
PPTX
Introduction to Modern and Emerging Web Technologies
PDF
Building Scalable Web Applications Using Microservices Architecture and NodeJ...
PDF
Transformation to a scalable architecture at ING
PPTX
Scalable Web Architecture and Distributed Systems
PPTX
OVERVIEW OF FACEBOOK SCALABLE ARCHITECTURE.
PPTX
Facebook architecture presentation: scalability challenge
PDF
Facebook Architecture - Breaking it Open
PPT
7 Stages of Scaling Web Applications
PDF
facebook architecture for 600M users
PDF
Architecture of a Modern Web App
Building Modern Web Apps with MEAN Stack
Scalable Angular 2 Application Architecture
Scalable Web Architecture
Introduction to Modern and Emerging Web Technologies
Building Scalable Web Applications Using Microservices Architecture and NodeJ...
Transformation to a scalable architecture at ING
Scalable Web Architecture and Distributed Systems
OVERVIEW OF FACEBOOK SCALABLE ARCHITECTURE.
Facebook architecture presentation: scalability challenge
Facebook Architecture - Breaking it Open
7 Stages of Scaling Web Applications
facebook architecture for 600M users
Architecture of a Modern Web App
Ad

Similar to Knowledge share about scalable application architecture (20)

PPS
Scalable Web Architectures: Common Patterns and Approaches - Web 2.0 Expo NYC
PPS
Web20expo Scalable Web Arch
PPS
Web20expo Scalable Web Arch
PPS
Web20expo Scalable Web Arch
PPS
Scalable Web Arch
PPS
Scalable Web Architectures - Common Patterns & Approaches
PPTX
Scaling your website
PDF
High Scalability Toronto: Meetup #2
PDF
Lessons from Highly Scalable Architectures at Social Networking Sites
PDF
Scalability Considerations
PPT
UnConference for Georgia Southern Computer Science March 31, 2015
PPTX
Application architecture for cloud
PPT
Large-scale projects development (scaling LAMP)
PPTX
Black Friday and Cyber Monday- Best Practices for Your E-Commerce Database
PPT
Technology Overview
PDF
The Web Scale
PDF
Dealing with Enterprise Level Data
PPTX
Mykhailo Hryhorash: Архітектура IT-рішень (Частина 1) (UA)
PDF
Scalability Design Principles - Internal Session
PDF
Scalability designprinciples-v2-130718023602-phpapp02 (1)
Scalable Web Architectures: Common Patterns and Approaches - Web 2.0 Expo NYC
Web20expo Scalable Web Arch
Web20expo Scalable Web Arch
Web20expo Scalable Web Arch
Scalable Web Arch
Scalable Web Architectures - Common Patterns & Approaches
Scaling your website
High Scalability Toronto: Meetup #2
Lessons from Highly Scalable Architectures at Social Networking Sites
Scalability Considerations
UnConference for Georgia Southern Computer Science March 31, 2015
Application architecture for cloud
Large-scale projects development (scaling LAMP)
Black Friday and Cyber Monday- Best Practices for Your E-Commerce Database
Technology Overview
The Web Scale
Dealing with Enterprise Level Data
Mykhailo Hryhorash: Архітектура IT-рішень (Частина 1) (UA)
Scalability Design Principles - Internal Session
Scalability designprinciples-v2-130718023602-phpapp02 (1)

More from AHM Pervej Kabir (16)

PPTX
Business Analysis.pptx
PPTX
Asp.net c# mvc Training-Day-5 of Day-9
PPTX
Asp.net c# mvc Training Day-4 of Day-9
PPTX
Asp.net c# mvc Training: Day-3 of Day-9
PPTX
Asp.net c# MVC-5 Training-Day-2 of Day-9
PPTX
Asp.net c# MVC-5 Training-Day-1 of Day-9
PPT
Software security engineering
PPT
Software security engineering
PPT
Shot note about project management
PDF
Data Collection From Field
PDF
Automated Survey Data Received and Sync From Field
PDF
Automated Survey Question Creator Management
PPTX
Presentation
DOC
Reporting about Overview Summery of ISO-27000 Se.(ISMS)
Business Analysis.pptx
Asp.net c# mvc Training-Day-5 of Day-9
Asp.net c# mvc Training Day-4 of Day-9
Asp.net c# mvc Training: Day-3 of Day-9
Asp.net c# MVC-5 Training-Day-2 of Day-9
Asp.net c# MVC-5 Training-Day-1 of Day-9
Software security engineering
Software security engineering
Shot note about project management
Data Collection From Field
Automated Survey Data Received and Sync From Field
Automated Survey Question Creator Management
Presentation
Reporting about Overview Summery of ISO-27000 Se.(ISMS)

Recently uploaded (20)

PDF
Upgrade and Innovation Strategies for SAP ERP Customers
PPTX
ai tools demonstartion for schools and inter college
PDF
Flood Susceptibility Mapping Using Image-Based 2D-CNN Deep Learnin. Overview ...
PDF
Softaken Excel to vCard Converter Software.pdf
PPTX
Agentic AI : A Practical Guide. Undersating, Implementing and Scaling Autono...
PPTX
ISO 45001 Occupational Health and Safety Management System
PPTX
history of c programming in notes for students .pptx
PDF
Which alternative to Crystal Reports is best for small or large businesses.pdf
PDF
Addressing The Cult of Project Management Tools-Why Disconnected Work is Hold...
PDF
Why TechBuilder is the Future of Pickup and Delivery App Development (1).pdf
PDF
top salesforce developer skills in 2025.pdf
PDF
How to Choose the Right IT Partner for Your Business in Malaysia
PDF
How Creative Agencies Leverage Project Management Software.pdf
PDF
2025 Textile ERP Trends: SAP, Odoo & Oracle
PPTX
Transform Your Business with a Software ERP System
PDF
medical staffing services at VALiNTRY
PDF
Claude Code: Everyone is a 10x Developer - A Comprehensive AI-Powered CLI Tool
PPTX
Materi-Enum-and-Record-Data-Type (1).pptx
PPT
JAVA ppt tutorial basics to learn java programming
PDF
AI in Product Development-omnex systems
Upgrade and Innovation Strategies for SAP ERP Customers
ai tools demonstartion for schools and inter college
Flood Susceptibility Mapping Using Image-Based 2D-CNN Deep Learnin. Overview ...
Softaken Excel to vCard Converter Software.pdf
Agentic AI : A Practical Guide. Undersating, Implementing and Scaling Autono...
ISO 45001 Occupational Health and Safety Management System
history of c programming in notes for students .pptx
Which alternative to Crystal Reports is best for small or large businesses.pdf
Addressing The Cult of Project Management Tools-Why Disconnected Work is Hold...
Why TechBuilder is the Future of Pickup and Delivery App Development (1).pdf
top salesforce developer skills in 2025.pdf
How to Choose the Right IT Partner for Your Business in Malaysia
How Creative Agencies Leverage Project Management Software.pdf
2025 Textile ERP Trends: SAP, Odoo & Oracle
Transform Your Business with a Software ERP System
medical staffing services at VALiNTRY
Claude Code: Everyone is a 10x Developer - A Comprehensive AI-Powered CLI Tool
Materi-Enum-and-Record-Data-Type (1).pptx
JAVA ppt tutorial basics to learn java programming
AI in Product Development-omnex systems

Knowledge share about scalable application architecture

  • 1. 1 Scalable Application Architecture Common Patterns & Approaches AHM Pervej Kabir & ERA-InfoTech Limited Cell:+8801757051005
  • 2. 2 Presentation Indicator  1. Introduction for understanding Scalable Apps.  2. Network Based Architecture  3. Application Based Architecture
  • 3. 3 Introduction Scalable Web Architectures? - What does scalable mean? - What’s an architecture? An answer has in next 12 parts.
  • 4. 4 Understanding- 1. Scaling  What is Scalable? Scalable means Expandable. Referring to hardware or software or application that can handle a large increase in users, workload or transactions without undue strain. Scalability is a system's ability to process more workload.  What is scalability not ?  Raw Speed / Performance  HA / BCP  Technology X  Protocol Y
  • 5. 5 Understanding- 1. Scaling  Objectives of scalability  Traffic growth  Dataset growth  Maintainability  Two kinds of scalability:  Vertical (get bigger)  Horizontal (get more)
  • 6. 6 Understanding-2.Architecture Architectures then?  The way the bits fit together  What grows where  The trade-offs between good/fast/cheap Storage array Cache AJAX!!!1 App server DatabaseInternet
  • 7. 7 Understanding-2.Architecture App servers scale in two ways:  Really well  Quite badly Sessions :  (State)  Local sessions == bad  When they move == quite bad  Centralized sessions == good  No sessions at all == awesome!
  • 8. 8 Understanding-2.Architecture Super slim sessions Properties:  If you need more than the cookie (login status, user id, username), then pull their account row from the DB  Or from the account cache  None of the drawbacks of sessions  Avoids the overhead of a query per page  Great for high-volume pages which need little personalization  Turns out you can stick quite a lot in a cookie too  Pack with base64 and it’s easy to delimit fields
  • 10. 10 Understanding-2.Architecture  Scaling the web app server part is easy  The rest is the trickier part  Database  Serving static content  Storing static content  Other services scale similarly to web apps  That is, horizontally  The canonical examples:  Image conversion  Audio trans coding  Video trans coding  Web crawling  Compute
  • 11. Hardware Load balance:  A hardware appliance  Often a pair with heartbeats for HA  Expensive!  But offers high performance  Many brands  Alteon, Cisco, Netscalar, Foundry, etc  L7 - web switches, content switches, etc 11 Understanding-3. Load Balancing
  • 12. Software Load balance:  Lots of options  Pound  Perlbal  Apache with mod_proxy  Wackamole with mod_backhand 12 Understanding-3. Load Balancing Wakamole
  • 13. Parallelizable:  If we can transcode/crawl in parallel, it’s easy  But think about queuing  And asynchronous systems  The web ain’t built for slow things  But still, a simple problem 13 Understanding-4. Queuing
  • 15. 15 Understanding-5. Relational Data Databases:  Unless we’re doing a lot of file serving, the database is the toughest part to scale  If we can, best to avoid the issue altogether and just buy bigger hardware  Dual Opteron/Intel64 systems with 16+GB of RAM can get you a long way Read Power of Apps:  Web apps typically have a read/write ratio of somewhere between 80/20 and 90/10  If we can scale read capacity, we can solve a lot of situations  Database replication!
  • 17. 17 Understanding-6. Caching  Caching avoids needing to scale!  Or makes it cheaper  Simple stuff  mod_perl / shared memory  Invalidation is hard  Database query cache  Bad performance (in most cases)  Getting more complicated…  Write-through cache  Write-back cache  Sideline cache
  • 18. 18 Understanding-6. Caching  Getting more complicated…  Write-through cache  Write-back cache  Sideline cache Write-through Write-back Sideline
  • 19. 19 Understanding- 7.HA Data  The key to HA is avoiding SPOFs  Identify  Eliminate  Some stuff is hard to solve  Fix it further down the tree  Dual DCs solves Router/Switch SPOF
  • 20. 20 Understanding-7. HA Data Master-Master:  Either hot/warm or hot/hot  Writes can go to either  But avoid collisions  No auto-inc columns for hot/hot  Bad for hot/warm too  Unless you have DB  But you can’t rely on the ordering!  Design schema/access to avoid collisions  Hashing users to servers
  • 21. 21 Understanding-7. HA Data Ring:  Master-master is just a small ring  With 2 nodes  Bigger rings are possible  But not a mesh!  Each slave may only have a single master  Unless you build some kind of manual replication
  • 22. 22 Understanding-7. HA Data Dual Tree:  Master-master is good for HA  But we can’t scale out the reads (or writes!)  We often need to combine the read scaling with HA  We can simply combine the two models
  • 23. 23 Understanding-8. Federation Data Federation:  At some point, you need more writes  This is tough  Each cluster of servers has limited write capacity  Just add more clusters  Split up large tables, organized by some primary object  Usually users  Put all of a user’s data on one ‘cluster’  Or shard, or cell  Have one central cluster for lookups
  • 24. 24 Understanding-8. Federation Data Federation:  Need more capacity  Just add shards!  Don’t assign to shards based on userid!  For resource leveling as time goes on, we want to be able to move objects between shards  Maybe – not everyone does this  ‘Lockable’ objects
  • 25. 25 Understanding-8. Federation Data Federation:  Need more capacity?  Just add shards!  Don’t assign to shards based on userid!  For resource leveling as time goes on, we want to be able to move objects between shards  Maybe – not everyone does this  ‘Lockable’ objects
  • 26. 26 Understanding-8. Federation Data Federation:  Heterogeneous hardware is fine  Just give a larger/smaller proportion of objects depending on hardware  Bigger/faster hardware for paying users  A common approach  Can also allocate faster app servers via magic cookies at the LB
  • 27. 27 Understanding-8. Federation Simple things first:  Vertical partitioning  Divide tables into sets that never get joined  Split these sets onto different server clusters  Logical limits  When you run out of non-joining groups  When a single table grows too large
  • 28. 28 Understanding-9. Multi-site HA Multiple Data centers:  Having multiple datacenters is hard  Not just with one DB  Hot/warm with DB slaved setup  But manual (reconfig on failure)  Hot/hot with master-master  But dangerous (each site has a SPOF)  Hot/hot with sync/async manual replication  But tough (big engineering task)
  • 29. 29 Understanding-10. File Servings  Serving lots of files is not too tough  Just buy lots of machines and load balance!  We’re IO bound – need more spindles!  But keeping many copies of data in sync is hard  And sometimes we have other per-request overhead (like auth.) Reverse Proxy
  • 30. 30 Understanding-10. File Servings  Serving out of memory is fast!  And our caching proxies can have disks too  Fast or otherwise  More spindles is better  We stay in sync automatically  We can parallelize it!  50 cache servers gives us 50 times the serving rate of the origin server  Assuming the working set is small enough to fit in memory in the cache cluster Reverse Proxy
  • 31. 31 Understanding-10. File Servings Invalidation:  Dealing with invalidation is tricky  We can prod the cache servers directly to clear stuff out  Scales badly – need to clear asset from every server – doesn’t work well for 100 caches  We can change the URLs of modified resources  And let the old ones drop out cache naturally  Or prod them out, for sensitive data  Good approach!  Avoids browser cache staleness  Hello Akamai (and other CDNs)
  • 32. 32 Understanding-10. File Servings Perlbal backhanding:  Perlbal can do redirection magic  Client sends request to Perbal  Perlbl plugin verifies user credentials  token, cookies, whatever  tokens avoid data-store access  Perlbal goes to pick up the file from elsewhere  Transparent to user
  • 33. 33 Understanding-10. File Servings Permission URLs:  If we bake the auth into the URL then it saves the auth step  We can do the auth on the web app servers when creating HTML  Just need some magic to translate to paths  We don’t want paths to be guessable
  • 34. 34 Understanding-11. Storing File  Storing files is easy!  Get a big disk  Get a bigger disk  Horizontal scaling is the key  Again Connecting to storage:  NFS  Stateful == Sucks  Hard mounts vs Soft mounts, INTR  SMB / CIFS / Samba  Turn off MSRPC & WINS (NetBOIS NS)  Stateful but degrades gracefully  HTTP  Stateless == Yay!  Just use Apache
  • 35. 35 Understanding-11. Storing File Multiple volumes:  Volumes are limited in total size  Except (in theory) under ZFS & others  Sometimes we need multiple volumes for performance reasons  When using RAID with single/dual parity  At some point, we need multiple volumes
  • 36. 36 Understanding-11. Storing File HA Storage:  HA is important for assets too  We can back stuff up  But we tend to want hot redundancy  RAID is good  RAID 5 is cheap, RAID 10 is fast  But whole machines can fail  So we stick assets on multiple machines  In this case, we can ignore RAID  In failure case, we serve from alternative source  But need to weigh up the rebuild time and effort against the risk  Store more than 2 copies.
  • 37. 37 Understanding-12. Field work  Flickr  Because we know it  LiveJournal  Because everyone copies it
  • 41. 41 Application Base Architecture Contain: 1. Why n-tier? 2. Layers. 3. Monolithic or 1-tier architecture. 4. 2-tier architecture. 5. 3-tier architecture. 6. Need of MVC. 7. MVC architecture. 8. MVC components. 9. Comparison between MVC and 3-tier.
  • 42. 42 Application Base Architecture 1. Why n-tier: Need of e-commerce solutions; increase in users and merchant sites all over the world. Applications should be scalable, user-friendly, have tight security and easily maintainable. 2. Layer: Layer means logical. Tier means physical. Generally there are three layers:- Presentation Business Data access layer
  • 43. 43 Application Base Architecture Layers Presentation: Presentation Layer: involves with client and application interaction. Provides user friendly interface for the clients. Business Layer: contains the application code or the core functionalities of the application or what the application will perform. Data access Layer: involves with the maintaining database and storage of data.
  • 44. 44 Application Base Architecture 3. Monolithic or 1-tier: 1.Presentation layer, Business layer and Data Access layer are tightly connected. As the layers are tightly connected(depends on each other), if any of the layer code are changed then other layers should be affected and the codes in other layers need to be changed. 2.Traditional approaches of the applications are based on this type of architecture. Typically implementation of 1-tier architecture can be a C program running in a computer. 4. 2-tier: 1.In this type of architectures the presentation layer, the business logic layer are separated from the data access layer. 2.The advantages of this layer is that the code of the data access layer can be changed any time without affecting the code of the other layer i.e. the whole database and the layer can be changed anytime. 3.The database(i.e. the data access layer) can be present anywhere around but the other two layers should be together(tightly connected). 4.As the presentation and the business logic are still connected they should be present at the client side to work together; due to the concentration of the client this type of client is called thick client. 5.Problems faced by this type of architecture is the client should always get the updated copies of the application if there is a change in the application codes or application developer modifies the application. 6.The application developer may not want to give the code to the relatively third parities even if the code is pre compiled
  • 46. 46 Application Base Architecture 5. 3-tier: 1.In this type of architecture the presentation layer, the business logic layer and the data access layer are separated from each other and are present on three different tiers therefore they are loosely connected. 2.The main advantages is that any change in the code in one layer will not affect the other layers and the platform can also be changed independently. 3.Now the web designer can concentrate on the design of the user interface i.e. the presentation logic, the application developer concentrate on developing the application i.e. the business logic and the database manager can handle the database independently. 4.Today’s application are based on 3-tier architecture which are scalable, easy to maintain, components are reusable and faster development
  • 47. 47 Application Base Architecture 6. Need Of MVC Architecture : Need to access the data from different context such as mobiles, touch screen, desktop, etc.  Need to show the data in different context such as mobiles, touch screen, desktop, etc.  Need to show multiple views of the same data such as Thumbnails, List or details. Need to change the designs without changing the core business logic. 7. MVC Solution:  Separate the core business logic form the presentation logic.  Separate views for the same data.
  • 49. 49 Application Base Architecture 8. MVC Component: Model: It contains the core functionalities and the business logic of the application. It accepts the state query from the model and controller and it provides the updated information to the view component. View: This component is responsible for the presentation logic and the user interaction between the application. The model provides different information to different user which can be represented in different ways. The main work of the view component is to provide the suitable information to the user. Controller: It accepts the user input through the view component and process them and if any changes are required then it perform the changes after that it response to the client 9. MVC Vs. 3-tier: 1. In MVC architecture the components communicate directly with each other in order to maintain a coherent user interaction but in case of 3-tier the presentation layer(front end) communicates with the data access layer(back end) through the business layer(middleware). 2. In 3-tier the Layers are present on three different tiers or machines where as in MVC the layers are present on single tier or machines.