mirror of
				https://github.com/donnemartin/system-design-primer.git
				synced 2025-11-04 10:12:32 +03:00 
			
		
		
		
	Add Caching at the database query level vs obj level sections
This commit is contained in:
		
							
								
								
									
										21
									
								
								README.md
									
									
									
									
									
								
							
							
						
						
									
										21
									
								
								README.md
									
									
									
									
									
								
							@@ -1252,3 +1252,24 @@ There are multiple levels you can cache that fall into two general categories: *
 | 
			
		||||
* Fully-rendered HTML
 | 
			
		||||
 | 
			
		||||
Generaly, you should try to avoid file-based caching, as it makes cloning and auto-scaling more difficult.
 | 
			
		||||
 | 
			
		||||
### Caching at the database query level
 | 
			
		||||
 | 
			
		||||
Whenever you query the database, hash the query as a key and store the result to the cache.  This approach suffers from expiration issues:
 | 
			
		||||
 | 
			
		||||
* Hard to delete a cached result with complex queries
 | 
			
		||||
* If one piece of data changes such as a table cell, you need to delete all cached queries that might include the changed cell
 | 
			
		||||
 | 
			
		||||
### Caching at the object level
 | 
			
		||||
 | 
			
		||||
See your data as an object, similar to what you do with your application code.  Have your application assemble the dataset from the database into a class instance or a data structure(s):
 | 
			
		||||
 | 
			
		||||
* Remove the object from cache if its underlying data has changed
 | 
			
		||||
* Allows for asynchronous processing: workers assemble objects by consuming the latest cached object
 | 
			
		||||
 | 
			
		||||
Suggestions of what to cache:
 | 
			
		||||
 | 
			
		||||
* User sessions
 | 
			
		||||
* Fully rendered web pages
 | 
			
		||||
* Activity streams
 | 
			
		||||
* User graph data
 | 
			
		||||
 
 | 
			
		||||
		Reference in New Issue
	
	Block a user