About me

Michael L Perry

Improving Enterprises

Principal Consultant

@michaellperry

User login

The CAP Theorem and its Implications

Please access the materials on line:

The CAP Theorem tells us that we have a choice. With our customer’s help, we choose the architecture that bets fits the system we are building. Some architectures guarantee Consistency and Availability. Others relax Consistency in favor of Partition Tolerance. Still others choose some guarantees for some subsystems and other guarantees for others.

In this talk, I present the definition and proof of the CAP Theorem. I then describe the different types of systems that benefit from different guarantees. Finally, I present three different architectures and demonstrate in code how they each uphold their own guarantees.

The slides are presented in Silverlight. This gives the presenter the ability to take notes in the sidebar, to pan and zoom through the diagrams, and to step through animations.

  • Click on the presentation to give it focus
  • F11 – Full screen
  • Page down – next slide
  • Page up – previous slide
  • Arrow down – next animation
  • Arrow up – previous animation
  • Drag to pan
  • Scroll wheel to zoom

The code is written in C# 4.0, and can be opened in Visual Studio 2010. Its 9 projects are grouped into 3 examples:

  • Central Database
    • Service – A web service that communicates with the database.
    • Client – A WPF client application that uses the web service.
  • CQRS
    • Messages – Data types used by both Service and Background to serialize messages in MSMQ.
    • Service – A web service that reads from the database and publishes messages to the queue.
    • Background – A console application that processes messages from the queue against the database.
    • Client – A WPF client application that uses the web service.
  • Event Sourcing
    • Service – A web service that calculates current balance and writes transfers to the database.
    • Background – A console application that writes balance snapshots.
    • Client – A WPF client application that uses the web service.

Activate the Task List view to follow the TODO comments through the code. Always look at the entity model before walking through source code.

To run the examples, you must first run the databases.sql script to create three databases:

  • CAP_CentralDatabase
  • CAP_CQRS
  • CAP_EventSourcing

Both the slides and the source code are licensed for your use under the Creative Commons Attribution 3.0 United States License. You are free to use either or both in any way you choose, including presenting the material yourself. Please retain the attribution in the title page.



CAP Theory

Submitted by Anonymous on Thu, 07/08/2010 - 11:06.

Dear Mr. Perry:

Just a quick note to thank you for the excellent presentation on CAP Theory last evening at NDDNUG. I had never even heard of CAP Theory before you taught me about it last night.

You are an affable and compelling speaker and I was mesmerized by your ideas, after I finally got on the same conceptual "page" as yours.

This theory has caused me to completely re-think my conception of high-transaction, distributed, relational database-driven, enterprise architecture. You proved, at least to me, that we can achieve our goals using SQL Server or other traditional databases.

So, let me see if I got this right:

1. The more we optimize our system for Partition Tolerance, the more impact we will have on short-term Consistency (but, we will eventually get complete Consistency, assuming all of the nodes are performing their functions correctly at the appropriate times).

2. But, we will optimally maximize Availability, which means excellent Presentation-Tier performance --which is awesome. Right?

This means that, avoiding database deadlocks by design, employing the durability of MSMQ and a reliance more on Business-Tier-to-Data-Tier INSERTS (rather than UPDATES), while using the database itself to do the UPDATES are absolutely essential concepts, in CAP Theory.

Now, the Maintenance and Deployment issues are different, here. As we evolve from version-to-version of the deployed components, we must ensure backward-compatibility, perhaps even at the Method-level. Over time, this could bloat our codebase and we must have a strategy for when we deprecate a Method or Class and when we simply remove them altogether.

The "Account Balance" example was a simple one; easy to understand. Now, I can't truthfully say that I have totally mastered this concept, yet. I am, nonetheless, fascinated by this theory.

Is there any way that I might gain access to the source code and presentation materials that you used last evening?

I am a bit of a dullard, so I need to really scrutinize the code within the Visual Studio environment in order to really understand it.

Also, I am recovering from an recent injury (I was in some physical pain last night), so I was a bit distracted by the pain.

If the code and presentation materials are available, I would be grateful if I might be able to download and study them.

Anyway, thank you for enlightening us. I look forward to seeing you again at NDDNUG. Please make another presentation, soon. I hope to be there when you do.

Warm regards, always,

david
http://www.davidtate.net

You got it

Submitted by Michael L Perry on Fri, 07/09/2010 - 13:06.

It sounds like you understand the material just fine. Your summary of the presentation is 100% correct.

I hope to have the opportunity to speak at NDDNUG again. There is much more to say on the topic of distributed systems architecture.

The links to the slides and source code were in the article. I've moved them to the top to make them easier to find.