Scribd
Upload
157 views29 pages

Building Scalable, Secure Web Api

The document discusses building scalable web APIs. It identifies four dimensions of scalability and explains that the two fundamental ways to scale software are vertically and horizontally. It advocates for designing systems using small, stateless microservices that communicate over HTTP and scale horizontally across multiple servers. Key principles for building scalable systems include embracing failure, automated deployments, and monitoring. REST is recommended as a methodology due to advantages like scalability, independence of components, and ability to cache responses.

Uploaded by

PrashanthYP
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
157 views29 pages

Building Scalable, Secure Web Api

The document discusses building scalable web APIs. It identifies four dimensions of scalability and explains that the two fundamental ways to scale software are vertically and horizontally. It advocates for designing systems using small, stateless microservices that communicate over HTTP and scale horizontally across multiple servers. Key principles for building scalable systems include embracing failure, automated deployments, and monitoring. REST is recommended as a methodology due to advantages like scalability, independence of components, and ability to cache responses.

Uploaded by

PrashanthYP
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 29

SCALABLE API

BUILDING SCALABLE, SECURE WEB API


Compiled from various sources - YP 1
Compiled from various sources - YP 2
Compiled from various sources - YP 3
DIMENSIONS OF SCALABILITY

Load Scalability
Functional Scalability
Integration Scalability
Geographic Scalability

Compiled from various sources - YP 4


2 FUNDAMENTAL WAY WE CAN SCALE
SOFTWARE

VERTICALLY
HORIZONTALLY

Compiled from various sources - YP 5


VERTICAL SCALING

Vertical Scalingaddresses the scalability of a single instance of the service. A simple


way to scale most software is simply to run it on a more powerful machine; one with a
faster processor or more memory. We can also look for performance improvements in
the way we write the code itself. An excellent example of company using this approach
isLMAX. However, there are many drawbacks to the vertical scaling approach. Firstly
the costs are rarely linear; ever more powerful hardware tends to be exponentially more
expensive and the costs (and constraints) of building sophisticated performance
optimised software are also considerable. Indeed premature performance optimisation
often leads to overly complex software that's hard to reason about and therefore more
prone to defects and high maintenance costs. Most importantly, vertical scaling does not
address redundantcy; vertically scaling an application just turns a small single point of
failure into a large single point of failure

Compiled from various sources - YP 6


HORIZONTAL SCALING

Horizontal Scaling.Here we run multiple instances of the application


rather than focussing on the performance of a single instance. This has the
advantage of being linearly scalable; rather than buying a bigger, more
expensive box, we just buy more copies of the same cheap box. With the
right architectural design, this approach can scale massively. Indeed it's the
approach taken by almost all of largest internet scale companies: Facebook,
Google, Twitter etc.. Horizontal Scaling also introduces redundancy; the loss
of a single node need not impact the system as a whole. For these reasons,
horizontal scaling is the preferred approach to building scalable, redundant
systems

Compiled from various sources - YP 7


FUNDAMENTAL APPROACH TO BUILD SCALABLE
SYSTEM COMPOSE THEM OF HORIZONTALLY
SCALED SERVICES
BASIC PRINCIPLES
Stateless
Coarse Grained API
Idempotent
Embrace Failure
Avoid instance specific configuration
Simple automated deployment
Monitoring
KISS [My favorite!] - Keep It Small and Simple

Compiled from various sources - YP 8


STATELESS
Any services that stores state across an interaction with another service is hard to
scale. For example, a web service that stores in-memory session state between
requests requires a sophisticated session-aware load balancer. A stateless service,
by contrast, only requires simple round-robin load balancing. For a web application
(or service) you should avoid using session state or any static or application level
variables.

COARSE GRAINED API


To be stateless, a service should expose an API that exposes operations as a single
interaction. A chatty API, where one sets up some data, asks for some transition,
and then reads off some results, implies statefulness by its design. The service
would need to identify a session and then maintain information about that session
between successive calls. Instead a single call, or message, to the service should
encapsulate all the information that the service requires to complete the operation.

IDEMPOTENT
Much scalable infrastructure is a trade-off between competing constraints. Delivery
guarantees are one of these. For various reasons it's is far simpler to guarantee 'at
least once' delivery than 'exactly once'.
Compiled from Ifsources
various you can- YP make your software tolerant of 9
multiple deliveries of the same message it will be easier to scale.
E M B R A C E FAI L U R E
Arrays of services are redundant if the system as a whole can survive the loss of a
single node. You should design your services and infrastructure to expect and
survive failure. Consider implementing aChaos Monkeythat randomly kills
processes. If you start by expecting your services to fail, you'll be prepared when
they inevitably do.

AVO I D I N S TAN C E S P E C I F I C C O N F I G U R ATI O N


Arrays of services are redundant if the system as a whole can survive the loss of a
single node. You should design your services and infrastructure to expect and
survive failure. Consider implementing aChaos Monkeythat randomly kills
processes. If you start by expecting your services to fail, you'll be prepared when
they inevitably do.
S I M P L E A U T O M ATE D D E P LOY M E N T
Have a service that can scale is no advantage if we can't deploy it when we
are close to capacity. A scalable system must have automated processes to
deploy new instances of services as the need arises

Compiled from various sources - YP 10


MONITORING
We need to know when services are close to capacity so that we can add additional
service instances. Monitoring is usually an infrastructure concern; we should be
monitoring CPU, network, and memory usage and have alerts in place to warn us
when these pass certain trigger points. Sometimes it's worth introducing application
specific alerts when some internal trigger is reached, such as the number of items in
an in-memory queue, for example
KISS - KEEP IT SMALL AND SIMPLE
This is good advice for any software project, but is especially pertinent to building
scalable resilient systems. Large monolithic codebases are hard to reason about,
hard to monitor, and hard to scale. Building your system out of many small pieces
makes it easy to address those pieces independently. Design your system so that
each service has only one purpose and is decoupled from the operations of other
services. Have your services communicate using non-proprietary open standards to
avoid vendor lock-in and allow for a heterogeneous platform. JSON over HTTP, for
example, is an excellent choice for intra-service communication. Every platform has
HTTP and JSON libraries and there is abundant off-the-shelf infrastructure (proxies,
load-balancers, caches) that can be used to help your system scale

Compiled from various sources - YP 11


Compiled from various sources - YP 12
Compiled from various sources - YP 13
POPULAR METHODOLOGIES

REST
SOAP
XML RPC

Compiled from various sources - YP 14


WHY REST?

Scalability
Generality
Independence
Latency (Caching)
Security
Encapsulation
Compiled from various sources - YP 15
Compiled from various sources - YP 16
Compiled from various sources - YP 17
Compiled from various sources - YP 18
Compiled from various sources - YP 19
Compiled from various sources - YP 20
Compiled from various sources - YP 21
Compiled from various sources - YP 22
Compiled from various sources - YP 23
Compiled from various sources - YP 24
Compiled from various sources - YP 25
Compiled from various sources - YP 26
Compiled from various sources - YP 27
Compiled from various sources - YP 28
Compiled from various sources - YP 29

You might also like