Scalable Web - Architecture Essentials

Modified on Sun, 26 Feb 2017 17:34 by Biswajit Dash — Categorized as: blueprint, classical architecture, web architecture, whiteprint

Problem Statement

What are the essential attributes of a scalable web system, and how to design such a system?

Table of Contents [Hide/Show]

Problem Statement
Solution Abstract
   What? What? How?
   The Inner-workings
      Architectural Flow
      Standard Web System
         Logical Architecture
         Deployment Topology
      x-domain Web System
         Logical Architecture
         Deployment Topology
   Implementation Matrix
Glossary
References

Solution Abstract

What? What? How?

What is a scalable web application? The basic function of a web server (web-site or web-application) is to serve static content like HTML, JS, CSS, etc., over HTTP/HTTPS channel, using a Request-Response model of communication. For any real-life web there will be added complexity on server-side like - complex logic execution, database access, application security etc. Along with these a scalable system needs to be - responsive, capable of processing large number of requests, and be able to scale to meet ever increasing load.

What are the key challenges? The key concerns being :-

reduce latency or time taken to serve a request from client - mostly computed in seconds if not sub-seconds;
improve throughput or the number of requests that can be processed in certain amount of time;
remove server resource contention like - memory, CPU, IO, bandwidth;
recover from hardware/software failure;
handle unexpected surge in load - either genuine or DoS like attack; and
support frequent deployments with minimal down-time.

How to solve the challenges? The architecture and design need to :-

have coarse-grained interface for reduced calls over network;
have specialized fine-grained interfaces for selective data transfer over network;
implement data-cache to reduce - database reads and CPU cycle;
implement content-cache to reduce - file-system reads;
partition data and content-files for improved reads and load-sharing;
design state-less components and APIs;
design self-sufficient context-agnostic components;
have load-balancing and clustering in place for load sharing and fault tolerance;
design specialized code to detect failure and use backup systems; and
support session persistence to enable recovery and scale-out;

The Inner-workings

For a system to be scalable, specialized implementation considerations are needed in - logical architecture and deployment architecture. While the logical construct remains same, there can be two key variants of the architectural structure -

standard - in which contents and calls are served from the same domain;
x-domain - in which the contents and calls are served/composed from multiple domains, resulting in x-domain (aka cross-domain) calls.

Architectural Flow

Standard Web System

In a standard web system contents are served to the web-browser from the same domain. Static resources like - css, javascript, images, etc., may be served from different domains/sub-domains over HTTP GET (occasionally using AJAX JSONP calls). Note: JSONP is a security vulnerability, and not preferred.

Logical Architecture

Deployment Topology

x-domain Web System

In a x-domain web system contents are served to the web-browser from multiple domain/sub-domains, over HTTP GET/POST/PUT/DELETE. This is specifically used in systems serving web-APIs and/or aggregated content. The architectural construct remains same as a standard web system, with the addition of reverse proxy.

Logical Architecture

Deployment Topology

Implementation Matrix

The below matrix depicts the implementation essentials and the problems they solve.

Glossary

RESTful API	Representational State Transition API. A web based simplified API working over HTTP QueryString parameters.
Static Content	The contents that do not change and are retrieved from direct file-system reads, like - html, text, script, image files.
XHR	XML Http Request. A built-in communication object available in browser over which all HTTP communication occurs.
Load Detector	A pass-through component which monitors the incoming requests and detects high-loads based on pre-defined thresholds. This is an optional module built into the web system.
Endpoint	The address or URL through which communication occurs.
Message Queue	A store-forward asynchronous system which can accept requests, persist it and later forward to the target system for processing.

References

Patterns & Prctices - Application Architecture Guide (Microsoft)

Paper Code: TWP_1002.11, Version: 1.1, Author: Biswajit Dash, License: CC-BY-ND, Published: Sep-2016