diff --git a/architecture/CACHING.md b/architecture/CACHING.md
index a7a5c53..3a8f601 100644
--- a/architecture/CACHING.md
+++ b/architecture/CACHING.md
@@ -39,8 +39,17 @@ As of now we have 3 different groups of cacheable EVM methods:
 - cacheable by block hash (for ex.: `eth_getBlockByHash`)
 - static methods (for ex.: `eth_chainId`, `net_version`)
 
-### Example of cacheable eth_getBlockByNumber method
+### Cacheable by block number
 
+Cacheable by block number means that for specific:
+- method
+- params
+- block height (which is part of params)
+response won't change over time, so we can cache it indefinitely
+
+NOTE: we don't cache requests which uses magic tags as a block number: "latest", "pending", etc... Because for such requests answer may change over time.
+
+Example of cacheable `eth_getBlockByNumber` method
 ```json
 {
 	"jsonrpc":"2.0",
@@ -53,7 +62,40 @@ As of now we have 3 different groups of cacheable EVM methods:
 }
 ```
 
-NOTE: we don't cache requests which uses magic tags as a block number: "latest", "pending", etc...
+### Cacheable by block hash
+
+Cacheable by block hash means that for specific:
+- method
+- params
+- block hash (which is part of params)
+response won't change over time, so we can cache it indefinitely
+
+So it similar to cacheable by block number, but even simplier because we don't have to deal with magic tags: "latest", "pending", etc...
+
+### Static methods
+
+Static methods doesn't depend on anything, so we can cache them indefinitely. 
+
+For example:
+
+```json
+{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":67}
+```
+
+```json
+{"jsonrpc":"2.0","method":"net_version","params":[],"id":67}
+```
+
+### Where to find list of methods for every group?
+
+It can be found in source code: https://github.com/Kava-Labs/kava-proxy-service/blob/main/decode/evm_rpc.go
+
+Look for corresponding lists:
+- CacheableByBlockNumberMethods
+- CacheableByBlockHashMethods
+- StaticMethods
+
+### TTL
 
 TTL can be specified independently for each group, for ex:
 ```
@@ -94,6 +136,27 @@ For example:
 
 `redis-cli KEYS "local-chain:evm-request:*" | xargs redis-cli DEL`
 
+### Invalidating all cache
+
+If you want to invalidate all cache the best way to do it is to use this command:
+
+`redis-cli -h <redis-endpoint> FLUSHDB`
+
+and then to make sure that cache is empty you can run:
+
+`redis-cli -h <redis-endpoint> KEYS "*"`
+
+alternative approach may be using this command:
+
+`redis-cli KEYS "*" | xargs redis-cli DEL`
+
+but it will fail due to big number of keys, so FLUSHDB is better
+
+### Redis endpoints (NOTE: it may change in the future):
+- internal-testnet: `kava-proxy-redis-internal-testnet.ba6rtz.ng.0001.use1.cache.amazonaws.com`
+- public-testnet: `kava-proxy-redis-public-testnet.ba6rtz.ng.0001.use1.cache.amazonaws.com`
+- mainnet: `kava-proxy-redis-mainnet.ba6rtz.ng.0001.use1.cache.amazonaws.com`
+
 ## Architecture Diagrams
 
 ### Serve request from the cache (avoiding call to actual backend)