當今，許多廣泛使用的數據庫系統是在整個公司採用單個數據庫的時代開發的。這個單一的數據庫系統將在一個地方存儲和運行企業的所有功能，可以想象一下：一個房間裡擺滿了冰箱大小的機器，許多房間都裝有超大型的盤式磁帶驅動器。
但是Redis的發展與許多其他流行的數據庫系統不同。Redis建於NoSQL時代，是一個靈活而通用的數據庫，而不是為存儲大量將大部分時間閒置的數據而服務的數據庫。微服務架構具有相似的目標：每種服務的設計都適合特定用途，而不是運行業務中的所有內容。
Redis旨在存儲經常更改和移動的活動數據，其不確定的結構沒有關係的概念。Redis數據庫佔用空間小，即使使用最少的資源也可以提供巨大的吞吐量。同樣，微服務體系結構中的單個服務僅關注該服務專用的輸入和輸出以及數據，這意味著Redis數據庫可以支持各種不同的微服務，每個微服務都具有自己的數據存儲。這很重要，因為擁有許多服務的本質意味著每個服務必須儘快執行，以彌補服務間通信帶來的連接和延遲開銷。
微服務體系結構的一個關鍵特徵是每個單獨的服務都獨立存在，該服務沒有與另一個服務緊密耦合。這意味著微服務必須維護自己的狀態，並且要維持狀態，這需要一個如之相配的數據庫。
微服務架構可以包含數百甚至數千個服務，而開銷卻是規模的敵人，僅消耗大量資源即可運行的基礎架構將削弱微服務架構的優勢。
理想情況下，服務數據應與其他數據層完全隔離，從而允許不耦合的擴展和跨服務爭用，以節省資源。由於服務是專門為填補單個角色而設計的（就業務流程而言），因此它們存儲的狀態本質上是非關係的，非常適合NoSQL數據模型。Redis可能不是微服務體系結構中所有數據存儲的一攬子解決方案，但是它確實可以滿足許多要求。
構建服務後，需要與其他服務進行對話。在傳統的微服務環境中，這是使用REST或類似約定在私有HTTP端點上發生的，收到請求後，服務將開始處理該請求。儘管HTTP方法行之有效並被廣泛使用，但還有一種替代的通信方法，即服務在類似日誌的結構中進行讀寫操作。在這種情況下，這就是Redis流，它允許使用異步模式，其中每個服務在自己的流上宣佈事件，並且僅偵聽屬於它感興趣的服務的流。這時，雙向通信是通過兩個服務相互觀察彼此的流來實現的。
但是，即使在不使用Redis進行存儲或通信的服務中，Redis仍然可以發揮至關重要的作用。為了提供低延遲的最終響應，每個服務都必須儘可能快地響應自己的請求，通常超出了傳統數據庫的性能極限。在這種情況下，Redis充當緩存的角色，其中服務的開發人員決定並非總是需要直接從主數據庫檢索數據的位置，而是可以更快地從Redis提取數據。
同樣，需要通過API訪問的外部數據服務也可能太慢了，可以在此處使用Redis來防止不必要且冗長的調用，從而提升系統的整體性能。
