CODEWITHSUNDEEP
design-patternsscalabilityhigh-availability
Chris Ballance
Chris Ballance

Reputation: 34337

Design Patterns (or techniques) for Scalability

What design patterns or techniques have you used that are specifically geared toward scalability?

Patterns such as the Flyweight pattern seem to me to be a specialized version of the Factory Pattern, to promote high scalability or when working within memory or storage constraints.

What others have you used? (Denormalization of Databases, etc.) Do you find that the rules change when high availability or scalability is your primary goal?

Possible situations are:

Upvotes: 26

Views: 15985

Answers (5)

user804979
user804979

Reputation: 933

What i have observed with Stateless application logic is that it introduces many other other requirements like locking on DB which eventually then work against scalability.

Lets say that the application logic deployed is stateless across a server farm then for a request which is hitting two nodes of a cluster at same time we have to introduce concepts like DB locking to make sure only one request will be processed.

I am dealing such situations now and was wondering how everyone else is dealing with such stateless behavior.

Upvotes: 1

Pascal Thivent
Pascal Thivent

Reputation: 570315

A few patterns that come in mind:

  • Stateless application
  • Loose coupling
  • Asynchrony
  • Lazy loading
  • Caching
  • Parallelism
  • Partitioning
  • Routing

Some resources:

Upvotes: 45

philsquared
philsquared

Reputation: 22493

The POSA (Patterns-Oriented Software Architecture) books are a great source for such patterns.

POSA 4, especially, is concerned with distributed computing, but all the volumns are full of scalability patterns.

Upvotes: 2

jldupont
jldupont

Reputation: 96716

Nothing is free - it comes down to what are the acceptable compromises in order to meet your business objectives. The main variables being:

  • Cost
  • Availability
  • Consistency
  • Survivability (e.g., Partition Tolerance)

An excellent paper to read on the subject.

I believe a good metric would be to examine the "cost/user" curve and try maintaining it to linear progression (assuming the acceptable cost per user is a known parameter :-)

The Design Patterns do play a role but it is the overarching architecture that matters most. One might have been very thorough at the module level but missed network level constraints and scalability suffers as a consequence.

At the end of the day, I believe one must ask himself (herself): for failure type X, how many "users" can be affected and for how long?

There will always be a SPOF (Single Point Of Failure) somewhere but one can engineer a system such that this SPOF is moved closer to the end-points (e.g. users). In many cases though, the SPOF is out of the control of the application e.g. network POP unavailable.

Anyway, I could spend hours on the subject...

Upvotes: 6

user151323
user151323

Reputation:

Make the application as stateless as possible. Will be easier to adapt to a server farm.

Upvotes: 10

Related Questions