Design Patterns (or techniques) for Scalability

Question

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

Patterns such as t

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

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

Answer 3

A few patterns that come in mind:

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

Some resources:

• Scalability Best Practices: Lessons from eBay
• Availability & Consistency presentation of Amazon's CTO Dr. Werner Vogels
• Microsoft PDC'08 Presentations
• Best Practices In Building Scalable Cloud Ready Service Based

Answer 4

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

Answer 5

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