Scaling Memcache at Facebook

In this video, we walk through the 2010 research paper "Scaling Memcache at Facebook." This paper has been very influential in companies building distributed caching systems.

For example, Uber and Twitter have caching systems inspired by Memcache.

The requirements of Memcache were:
1. Easy adoption, minimal APIs
2. Low Latency
3. Very High Availability (without sacrificing too much on consistency)
4. Large globally distributed system

The design choices of Memcache are influenced by the above, as we will see in this video.

Chapters:
00:00 Background
02:30 Design Choices
05:35 Encouraging Adoption
09:58 Cache Architecture
12:59 Optimizations
17:33 Scaling The Cache
21:39 Hail Availability!
26:30 Scaling The Database
31:29 Thank you!

#SystemDesign #Caching #ResearchPaper

[gkcs]

Folks, apologies for the background noise. I never seem to get the tech right 😅

Thank you for watching, I am looking forward to seeing you again soon 🦸

[surendrapandey]

I knew the concepts of sharding and replication theoretically, but after seeing their usage in this system, I got a better understanding. Thanks for making easy-to-understand and fun videos!

[aldroid]

Thanks for the effort man….your videos are great and are of great help

[DeepLearningTalk]

Great summary video Gaurav 👏

Few pointers you may consider to cover:
* Lease concept to mitigate stale sets and thundering herd to persistent DB
* McRouter intermediary component to batch invalidation requests and minimise network congestion
* Remote Marker concept to tackle stale set problem arising from eventual consistency during cross-region replication from leader to follower

[DD-dsui]

thank you Gaurav for teaching us 🙏🏽 This is kind of knowledge is out of bound for us older and self-taught developers.

[satyamjha]

Amazing video! Loved it! Hoping to get more videos on whitepaper series soon!

[varungupta]

I'm an AWS engineeer and it's so interesting to see how most of the building blocks are actually used in a similar way for Amazon products. The whole mcsqueal idea is very similar to the Alf journal which is a tier 0 service at AWS.. everything from SQS to Aurora (amazon's spin on the sql db backed by an append only log) to S3 depend on Alf.

[omartoma]

8:49 Engineers are like everyone else [pause] are lazy, that killed me
Great video 👏🏼

[vipulkumar]

Thanks a lot Gaurav 🙏 It's always some value addition to my design knowledge 👌 Thanks a lot ❤

[jrajesh]

Great video. Could you explain about choosing cache sizes and if its use case dependent or how will it adapt to changing use cases .

[marksmanop]

What's better than Gaurav explaining a concept? Two Garurav's XD

[blasttrash]

why cant they use redis? was redis not there in 2010? or was it not feasible for their usecase?

[ssingh-]

how does mysql shares the changelog to mcsqueal?

[tarungarg]

How can sharding be replaced by replication?

[gouravprasad]

wht if they had used configuration provider like kafka for the sharding approach? obvio it was not available then... just a thought...

[abhiskh]

So, in replication - we will have replication of whole Facebook database in a cache (muiltple times)? Can you please clarify

[karan-ohth]

In final section (data consistency ) at 29:30, when we are using Bin Logs, how do they resolve data conflicts b/w ind server and us server ?
does McSQUEAL handle that or its just rollback ?

[shivambansal]

Replication makes more sense than sharding 🤣 What?

How long will you vertically scale each replica? There has to be sharding, replication can't replace it.

[mayankrathore]

Most popular question these days,
Design distributed counter where we can see burst of write on counter,

multiple solutions
1. range distribution ->
1.1. Once range distributor exhausted all ranges and some range are available on other app server how to borrow order id from neighbor app servers.
1.2. Commit of order since we want atomicity as well.

2. Sharding

It is Good topic to cover :)