Mene ne distributed cache, kuma yaya ake magance gazawarsa?

Question

IT Interview Practice · Accepted Answer

**Distributed cache tana barin application instances da yawa su sake amfani da data ta hanyar network.** Manufarta ita ce guje wa maimaita aiki mai tsada, tare da ƙa’idoji bayyanannu na freshness da failure.

Ka yi tunanin backend instances uku suna karanta product catalog ɗaya. Da cache a cikin kowane process, kowanne yana riƙe kwafinsa. Da shared cache service, instance ɗaya zai iya sanya value da sauran za su yi amfani da ita. Cache service kanta na iya amfani da nodes da yawa.

## 1. Yanke abin da za a iya cache cikin aminci

Fara da kuɗin samar da data da tsawon lokacin da za ta iya zama tsohuwa. Product description na iya jure ɗan jinkiri; final stock check na sayayya na iya buƙatar authoritative data.

Bayyana key da take gane cikakken result, ciki har da tenant, language da sauran inputs masu tasiri. In ba haka ba, cache mai sauri za ta iya ba da data ta customer marar dacewa. Riƙe database a matsayin authority ga durable business records, domin cached values za su iya ɓacewa.

## 2. Bi read path kafin tsara updates

Hanya ta gama gari ita ce cache-aside: application yana duba cache, ya karanta database idan babu value, sannan ya ajiye result tare da expiry time da ake kira TTL.

```text
Request -> Cache -> hit  -> Return value
                 -> miss -> Database -> Fill cache -> Return value
```

Hakan yana rage maimaita karanta database idan requests da yawa suna neman value ɗaya. Amma yana ƙara network calls da dependency, don haka cache tana amfani ne idan aikin da aka kauce ya fi waɗannan kuɗaɗen. Duba [Redis cache-aside](https://redis.io/docs/latest/develop/use-cases/cache-aside/).

## 3. Yanke yadda updates za su bayyana

Ga catalog, fara da commit na database update sannan invalidate cached product hanya ce mai amfani. Reader na gaba ya sake loda shi. Amma akwai race: reader zai iya karanta tsohuwar value kafin commit, sannan ya saka ta cache bayan invalidation.

TTL yana takaita tsawon rayuwar wannan kwafin da aka sake cache; ba ya tabbatar kowane read zai ga latest write nan take. Idan tsofaffin permissions, prices ko balances za su karya ƙa’idar operation, duba authoritative data ko tsara version-aware updates masu tabbaci bayyananne. Zaɓi consistency bisa aikin kasuwanci, kada ka ɗauka cewa Redis ya warware shi.

## 4. Hana cache miss zama outage

Idan popular entry ta expire, callers da yawa za su iya karanta database lokaci guda. Wannan cache stampede ne. Cache outage na iya haifar da abu ɗaya ga entries da yawa.

- Haɗa concurrent loads na key ɗaya don rage waɗanda za su sake gina ta; bayyana ko coordination na process ɗaya ne ko duk instances.
- Bambanta expiry times don entries da yawa kada su expire tare. Wannan yana raba refresh work amma ba ya warware kowace hot-key problem.
- Ba da tsohuwar cached value yayin refresh kawai idan kasuwanci ya yarda da stale data.
- Yi short cache timeouts kuma takaita database fallback traffic. Ƙin wani aiki na iya fi aminci da cika database har duk requests su gaza.

Gwada waɗannan paths da gangan. High hit rate a normal operation ba ya nuna sosai yadda service za ta yi idan cache ta ɓace.

## 5. Yi scaling bisa ainihin bottleneck

Sharding yana raba keys tsakanin cache nodes; replication yana riƙe copies don availability ko reads. Suna magance matsaloli daban. Redis Cluster yana amfani da hash slots don placement, saboda haka ƙara nodes ba ya raba aikin hot key ɗaya kai tsaye. Duba [Redis Cluster specification](https://redis.io/docs/latest/operate/oss_and_stack/reference/cluster-spec/).

Sa ido kan hit rate, request latency, timeouts, memory, evictions da load da yake isa database. Eviction yana nufin cache ta cire value don sarrafa memory, kuma zai iya faruwa kafin TTL. Kada a ɗauki cache entry a matsayin guaranteed durable storage ga business data ko queued work.

Ga catalog, zan fara da cache-aside mai explicit keys, freshness policy da protected fallback. Zan ƙara cache nodes ne idan measurements sun nuna capacity problem da distribution zai iya warwarewa. **Cache design mai kyau yana bayyana abin da zai faru idan value tana nan da kuma idan ba ta nan ko ba ta daidai ba.**

1. Yanke abin da za a iya cache cikin aminci

2. Bi read path kafin tsara updates

3. Yanke yadda updates za su bayyana

4. Hana cache miss zama outage

5. Yi scaling bisa ainihin bottleneck

Tambayoyi masu alaƙa