Kaip suprojektuoti sistemas, kurios gracingai tvarko nesėkmes?

Question

Accepted Answer

Esant dideliam mastui, **nesėkmos yra neišvengiamos** — serveriai sugenda, tinklas nepavyksta, priklausomybės tampa neprieinamos. Projektuojant atsižvelgiant į nesėkmes, reikia kurti sistemas, kurios **toleruoja ir atsistato iš nesėkmų gracingai**, o ne darant prielaidą, kad viskas veikia. Tai yra nezbūtina patikimiems sistemoms.

## Projektuoti atsižvelgiant į nesėkmes (nuomonė)

```text
ASSUME things WILL fail → at scale, failures are NORMAL, not exceptional:
  → servers crash, networks partition, disks fail, dependencies go down, traffic spikes
  → design systems to EXPECT and HANDLE failures gracefully (not assume everything works)
→ "everything fails all the time" → build resilience in.
```

## Atsparumo technikos

```text
✓ REDUNDANCY → multiple instances, no single point of failure (failover to healthy ones)
✓ RETRIES (with backoff) → retry transient failures (with exponential backoff + jitter to
  avoid overwhelming a recovering service)
✓ TIMEOUTS → don't wait forever for a failing dependency (fail fast)
✓ CIRCUIT BREAKERS → stop calling a failing service temporarily (prevent cascading failures;
  give it time to recover) → fail fast and fall back
✓ GRACEFUL DEGRADATION → reduced functionality vs total failure (e.g. show cached/partial
  data if a service is down)
✓ FALLBACKS → a default/alternative when something fails
✓ BULKHEADS / isolation → contain failures (one part failing doesn't sink everything)
```

## Išvengiant krūvinės nesėkmų

```text
⚠️ CASCADING failures → one failure triggers others (e.g. a slow service exhausts callers'
  resources → they fail too → spreads)
→ prevent with: timeouts, circuit breakers, isolation/bulkheads, load shedding, backpressure
✓ MONITORING/alerting → detect failures fast; test failure scenarios (chaos engineering)
```

## Kodėl tai svarbu

Supratimas, kaip suprojektuoti sistemas, kurios gracingai tvarko nesėkmes, yra vertingas, nes **nesėkmos yra neišvengiamos esant dideliam mastui**, ir jų projektuoti yra nezbūtina patikimiems sistemoms, todėl tai svarbi sistemos projektavimo žinios.

Pagendrinė nuomonė — **daryti prielaidą, kad dalykai sugės** (nes esant dideliam mastui, nesėkmos yra normalus, o ne išimtinis dalykas — serveriai sugenda, tinklai yra padalyti, priklausomybės žlugsta) ir kurti sistemas, kurios tikisi ir gracingai tvarko nesėkmes, o ne darant prielaidą, kad viskas veikia — tai yra patikimų sistemų kūrimo pagrindas, aprašytas principu, kad „viskas žlugsta nuolat.