I am in the process of implementing a small web application using memcached for caching objects and sql server for database persistence.

In all the projects I have done before I have done inserts/updates in the web thread itself. In this project I want to implement asynchronous inserts and updates. I will use memcached http://en.wikipedia.org/wiki/Memcached to capture changes and an external service (windows service) to persist the changes in db.

I understand premature performance tuning is evil but this is just a test project to learn memcached.

Has anybody done this before. What are the disadvantages of using this ?

  • I would not have chosen memcache. It lacks some basic durability and consistency guarantees that are probably necessary for your use case (but are not necessary for its primary use cases). Commented Oct 28, 2011 at 5:57
  • What are the other caching mechanism I can look into
    – NRS
    Commented Oct 28, 2011 at 6:13
  • You aren't using a cacheing mechanism at all. You're writing to memcache and then eventually persisting those changes using some service. That's not how cacheing works. Commented Oct 28, 2011 at 17:14

2 Answers 2


This approach greatly changes the ACID guarantees of your application. If your memcached server goes down, you lose all changes since your last database synch with no way of recovering them. Out of the box, memcached will throw out old values when it runs out of RAM. If your app is write-heavy, this could mean losing data between synchronization.

You can improve the chances of data making it into the database by adding redundancy to your memcached layer, but it still doesn't create a solution with the same guarantees as a relational database. This isn't always a disadvantage. Some NoSQL approaches are consciously trading ACID guarantees for performance and scalability. There's even some math behind it in Brewer's CAP Theorem.

Regardless, most non-ACID NoSQL solutions guarantee eventual consistency. That's something your current approach doesn't provide and most users won't live without. If you lose my order, enlightening blog post, or witty comment, I'll likely find a different software provider.


The disadvantage is that you're using distributed systems.

The advantage is that you're using distributed systems.

Knowing the strengths, weaknesses and potential gotchas with distributed systems is something that is key for anyone wanting to move into high traffic applications, whether they're web based or not. It changes the way that you think about your system architecture.

Using distributed systems will make your applications much more complex than they would be otherwise.

Are you building this small application as an excercise in understanding distributed systems? If not, I'd venture to say that you're hitting a nail with a sledgehammer and most likely signing yourself up for a ton of headaches that you would otherwise avoid.

  • I am building this application as an exercise to understand distributed system. I plan to migrate this to aws
    – NRS
    Commented Oct 28, 2011 at 3:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.