現在一些。NET開發人員開始放棄ASP.NET內置的緩存機制，轉而使用Memcached——一種分布式的內存緩存系統，其最初是由Danga Interactive公司為LiveJournal網站而開發。
存的一個基礎性問題就是如何處理過時數據。當運行在單獨的Web服務器上，你可以很容易地清除一個已經確認被改變了的緩存。可惜，ASP.NET沒有一個很好的方法來支持多服務器。每個服務器上的緩存都對其他緩存的改變一無所知。
ASP.NET允許通過基於文件系統和數據庫表的觸發器來作廢一個緩存。然而，這也存在問題，比如數據庫觸發器需要使用昂貴的輪詢，以及觸發器本身冗長的編程。但是，我們還是有其他的選擇的。
不像ASP.NET內置的緩存機制，Memcached是一個分布式的緩存系統。任何Web服務器都能更新或刪除一個緩存項，並且所有其他的服務器都能在下次訪問這些緩存項的時候自動獲取到更新的內容。這是通過把這些緩存項存儲在一個或者多個緩存服務器上來實現的。每一個緩存項都根據它的關鍵字的哈希值來分配到一個服務器上。
表面看來，Memcached針對ASP.NET的API就像和內置的API一樣。這讓開發人員很容易地轉換到Memcached上，僅僅通過在代碼中查找和替換即可實現。
然而僅僅只是讓其運行起來還不夠，如果要在大型Web Farms（譯者注：大型站點）正確地使用還需要注意一些問題。Richard Jones寫到：
當我們添加很多節點後，get_multi函數的有用性在降低——這可能是由於單獨的頁面，需要訪問幾乎所有的Memcached實例。我在某處讀到 Facebook（譯者注：現在很火的校園社交網站）把他們的Memcached集群進行分割以提高get_multi的性能（例如，所有用戶的數據都放置在名為mc的子集節點上）。有人能告訴我這樣做的效果嗎？
一個被推薦的解決方案是不根據緩存項的關鍵字來生成哈希鍵值。這將允許開發人員能夠讓一個給定頁面中需要的所有緩存項，盡量存放在同一個服務器上。可惜，基於數據保存的地方而不是基於緩存項自身的關鍵字來生成哈希鍵，很容易產生錯誤，需要仔細來實現（這個算法）。
