A while back I wrote Architecture You Always Wondered About: Lessons Learned at Qcon, where i summarized some of the lessons learned from the Amazon, eBay, Yahoo and LinkedIn architectures, which enabled them to address their scalability requirements.
During that conference I spoke about the limitations of existing tier-based implementations and presented a pattern (Space-Based Architecture) that outlines how one can apply some of these lessons to scale out existing applications in a relatively seamless manner by pushing the complexity to the underlying middleware stack.
The presentation is now available online at InfoQ:
The theory and principles behind this pattern are based on Lean methodology, which I discussed in Moving to Extreme Transaction Processing using Lean methodology.
- Implement a common cluster for the entire system, including
messaging and data. A common cluster eliminates the need for
redundancy when we introduce fail-over. It also removes the need for a transaction
coordinator, as we are no longer dealing with coordination of two separate
sub-systems (we also eliminate the need for idempotency).
- Remove disk I/O from the critical path of the transaction.
The state of the messaging middleware and in-flight transactions will
be stored purely
in-memory. The system will replication to keep a copy of the data in an
instance for hot fail-over. Synchronization with the back-end database
will be a background process using reliable asynchronous replication.
This way we
guarantee the consistency and availability of the system purely
depending on disk storage. This approach has a nice cost-benefit to it
well, as it reduces the need for expensive disks as part of the
- Collocate the business logic with the data. This reduces the network hops as well as the number of moving parts in the system.
- Partition. We split (or “shard”) the transactions into self-sufficient units
I hope you’ll find it interesting.