過去10年間で達成されてきた重要な業績のひとつに，クラウドベースシステムに代表される 一般ユーザ向け スケーラブルシステムの広範囲な普及と，いくつかの Web アプリケーションに見られる スーパースケーラビリティ とがある。たとえば Facebook は 平均で毎秒 1,300万，ピーク時には毎秒 45億のリクエストを処理している。これほどの成果を上げながらも，スケーラブルシステムを支えるコンセプトとアーキテクチャは今なお，急速な進化を続けている。カリフォルニアを拠点とするソフトウェアアーキテクトの Ricky Ho 氏は３年ほど前，当時最先端のスケーラブルシステムに関して，詳細な記事を自身のブログに書いた。そして３年を経た現在，その問題について再検討する時だと考えている。
スケーラビリティとは，拡張がパフォーマンスやコスト，メンテナンス性，その他の面に及ぼす悪影響を低減することである。
最新のポスト にはパターンを列挙している。
- ロードバランサ
- 分散と集中
- 結果キャッシュ (Result Cache)
- 共有スペース (Shared Space，別名 Blackboard)
- パイプとフィルタ
- マップリデュース (Map Reduce)
- バルク同期並列 (Bulk Synchronous Parallel)
- 実行オーケストレーション (Execution Orchestration)
ロードバランシングと結果キャッシュ，マップリデュースは以前からあったものだが，ソーシャルメディアが原因で発生した新たな問題をターゲットとするパターンもいくつかある。たとえばバルク同期並列は 80年代に発明された もので，Google の Pregel グラフ処理プロジェクト で採用されている。このプロジェクトは，３つの汎用的な処理パターンをサポートする。
- キャプチャ (例; ソーシャルネットワーク上で John が Peter に接続する場合，２つの Person ノード間にリンクを生成する)
- クエリ (例: John の友人の友人で，30歳未満の既婚者を検索)
- マイニング (例: シリコンバレーで最も影響力のある人物の検索）
続いて氏は，実行オーケストレーションパターンを説明する。
インテリジェンスを持ったスケジューラ(scheduler) およびオーケストレータ(orchestrator) で構成されるこのモデルでは，単純なワーカで構成されるクラスタ全体から，起動可能なタスクが (依存関係グラフに基いて) 選択され，スケジュールされます。
氏の記すところでは，このパターンは Microsoft の Dryad プロジェクト で使用されている。このプロジェクトは，“コンカレントプログラミングの知識を必要とせずに，数千台のマシンを使用” 可能にする，というものだ。
Dryad を使用するプログラマは，はじめに逐次実行プログラムをいくつか書き，それらを一方向チャネルで接続します。これにより，プログラムを頂点，チャネルをエッジとした有向グラフとして計算処理が構成されます。つまり Dryad の役割とは，任意の非循環有向グラフを合成可能なグラフ作成機なのです。Dyna が作成したグラフは，計算中に発生する重要なイベントに対応して，実行時に変更することができます。
10年前には考えも及ばなかったようなスケーラビリティが，今日ではごく日常的に達成されている。その次の限界はどこだろう？ スケーラブルシステムの構築に関して，読者はどのような経験をお持ちだろうか？ 不足しているものは何だろう？