26

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:

  • Mobile devices with more limited memory, processing power, and connectivity than a Desktop or Laptop
  • High # of users on limited hardware (caching strategies, etc)
  • Optimization of database schema for efficiency in lieu of a normalized design (e.g. SharePoint column wrapping for storage)
Chris Ballance
  • 33,810
  • 26
  • 104
  • 151
  • 1
    Could you define scalability in your question. Scalable in what regard, and possibly by how much. – NomeN Sep 17 '09 at 15:10
  • Your question makes no sense I'm afraid, patterns solve problems (at best) and you havent mentioned any problem in your post. You haven't even mentioned that sort of application you are talking about - is it web based? – Justin Sep 17 '09 at 15:14
  • 1
    @kragen2uk What about it doesn't make sense and elicits a downvote? Currently studying patterns used to deal with programming problems in which scalability is the primary concern. – Chris Ballance Sep 17 '09 at 15:20
  • @NomeN Thanks for the recommendation, I have added some possible situations – Chris Ballance Sep 17 '09 at 15:43
  • @Chris What I'm saying is that patterns only provide guidance for solving problems - there is no "Reduce CPU use on a web farm" pattern. For example the flywight pattern helps solve the problem of poor performance when using a large number of similar objects, but I dont see what gives this pattern a higher status than say, tweaking indexes of a poorly performing database, or trimming unneccessary ViewState from an Asp.Net app. All 3 are simply techniques that can be used in a certain situation. (I dont like design patterns :-p) – Justin Sep 17 '09 at 16:38

5 Answers5

45

A few patterns that come in mind:

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

Some resources:

Pascal Thivent
  • 562,542
  • 136
  • 1,062
  • 1,124
10

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

6

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...

jldupont
  • 93,734
  • 56
  • 203
  • 318
2

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.

philsquared
  • 22,403
  • 12
  • 69
  • 98
1

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.

user804979
  • 913
  • 1
  • 6
  • 9
  • I would consider putting the requests into a FIFO queue to decouple the request from the system further. That way, you would avoid DB locks. – Georgi Koemdzhiev Sep 29 '22 at 10:18