Ruani & interrogoni historinë e transaksioneve për qindra miliona llogari

Question

IT Interview Practice · Accepted Answer

**Partition-oni ledger-in sipas llogarisë dhe kohës, mbani të dhënat e fundit të nxehta dhe ato të vjetra të ftohta, dhe trajtoni rreshtat si një ledger append-only e pandryshueshme — kështu që historia e një llogarie të vetme është një pjesë e vogël e indeksuar, kurrë një skanim i miliarda rreshtave.** Access pattern-i është gjithmonë "një llogari, një interval datash", kështu që partition-oni për t'u përputhur me të.

## Arkitektura

```text
Write ─▶ Ledger table (append-only, immutable)
          partition by (account_hash, month)
              │
     ┌────────┴─────────┐
  HOT tier            COLD tier
  last 3 mo           older
  Postgres/SSD        S3/Parquet, Glacier
     │                    │
  index-seek        keyset paginate ──▶ API (account+range)
```

## Si funksionon

- **Partition sipas llogarisë + kohës.** Hash-oni account id-në në N buckets, pastaj range-partition sipas muajit. Një query për një llogari/muaj godet saktësisht një partition — DB pastron pjesën tjetër. Kjo kufizon çdo lexim pavarësisht madhësisë totale.
- **Ledger e pandryshueshme.** Kurrë mos bëni `UPDATE` të një transaksioni; korrigjimet janë rreshta të rinj reverses. Kjo jep një audit trail, replikim të sigurt, dhe ju lejon të bëni cache agresivisht (rreshtat kurrë nuk ndryshojnë).
- **Hot/cold tiering.** Mbani ~3 muajt e fundit në SSD/Postgres të shpejtë për lexime me latency të ulët; rrotulloni partitions më të vjetër te **S3/Parquet** (interroguar përmes Athena/Trino) ose Glacier. 95% e query-ve godasin të dhënat e fundit, kështu që shumica e magazinimit mund të jetë e lirë.
- **Keyset pagination.** Faqoni me `WHERE (ts, id) < (:last_ts, :last_id) ORDER BY ts DESC LIMIT 50` — jo `OFFSET`. Offset skanon dhe hedh rreshtat e kapërcyer; keyset kërkon index-in drejtpërdrejt, O(1) për faqe.

## Këndvështrimi i intervistës

Intervistuesi heton **zgjedhjen e partition-key** dhe **pagination**. Përgjigjet e mira thonë "partition sipas llogarisë"; përgjigjet e shkëlqyera shpjegojnë **pse keyset mund OFFSET** në faqe të thella, pse **ledger-i është i pandryshueshëm** (auditueshmëri, pa lock contention), dhe si **tiering** pret koston. Një kurth është një tabelë e vetme gjigante me një composite index — funksionon derisa index-i të mos hyjë më në RAM dhe çdo lexim të bëhet disk-bound.

## Kompromiset & gabimet

- **Partition key është i vështirë të ndryshohet.** Zgjidhni account+time që në fillim; re-partitioning i qindra milionave rreshtave më vonë është një projekt migrimi.
- **Query-t cross-account vuajnë.** "Vëllimi total nëpër të gjitha llogaritë" tani bën fan-out nëpër partitions — shtyjini ato te një OLAP rollup në vend të kësaj.
- **Leximet e ftohta janë të ngadalta.** Marrja e një statement 3-vjeçar nga Glacier merr minuta; vendosni pritjet e përdoruesit ose bëni pre-warm sipas kërkesës.
- **Hot partitions.** Një llogari whale ose muaji aktual mund të jetë një hotspot; sub-partition ose cache atë.
- **Kur jo:** miliona rreshta (jo qindra miliona) hyjnë në një Postgres table të vetme të indeksuar — mos ndërtoni tiering që nuk do t'ju duhet. Kapeni pas kësaj në shkallën ku index-i i një tabele të vetme ndalon së hyri në memorie.

Arkitektura

Si funksionon

Këndvështrimi i intervistës

Kompromiset & gabimet

Pyetje të ngjashme