Skip to content
#Software

How the CPU Recycling Department Became an Iron Savings Department That Can Stand the Load 1 RPS

#Software #Architecture #SoftwareArchitecture #SystemDesign #DistributedSystems #Management

Good. article from Ozon on caching on the example of creating a product-facade service, which will be a single cache over all master systems in Ozon. The service was loaded. (1 mln rps, 350 Gb/s in peak for distribution). It is interesting to read about different strategies for working with cache as sophistication increases.

  • lazy caching (where it all began) and then issues of disability cache with versioning, tags, TTL, events from Kafka for disability
  • **read-through caching
  • write through caching** Further, the interesting part about the choice of local or external cache storage and why it depends, here the design of the solution and the pros and cons of each approach and how and for what to combine them are clearly disassembled. And then good about the fight for hitrate and cache displacement strategies (LRU, LFU, Segmented LRU) And what to do about the thundering herd problem. And finally, a little about how to cache a solution completely smeared with caches:)

In the end, the authors give a good checklist of questions to ask yourself before you start cacheting.

Is it safe to use a cached value?

  • What is the permissible lifetime of objects in cache? Is it acceptable to delay updating the cache due to changes in the data or should it be disabled immediately?
  • How often does the data change? What is the expected amount of cached data?
  • What are the expected request scenarios (user behavior)?
  • Are hot keys expected, which will account for the main reading load?
  • Will the caching work?

From an engineering point of view, the article is very good. While reading, I remembered my Vietnamese flashbacks with caching, and it was quite pleasant to read some moments in a well-described form. But in terms of architecture design and team collaboration, it seemed to me that a separate department that caches all the data for everyone is a solution that works on a certain scale and that doesn't scale well to a large organization. We get ala DWH, but not behind, but front:) As a result, the responsibility for getting into the cache, setting up the cache, obtaining effective data from sources and correct disability falls on a centralized team, and should in theory be the responsibility of the product teams themselves.

#Software #Architecture #SoftwareArchitecture #SystemDesign #DistributedSystems #Management