როგორ გააკეთებთ მასშტაბის შეფასებას და ტევადობის დაგეგმვას?

Question

Accepted Answer

**შეფასება და ტევადობის დაგეგმვა** — მოსალოდნელი დატვირთვის, მონაცემების მოცულობისა და რესურსების საჭიროების გამოთვლა — სისტემის დიზაინის მნიშვნელოვანი ნაწილია. უხეში "ხელიერ" გაანგარიშებები ეხმარებიან დიზაინის გადაწყვეტილებებში (რამდენი გაძლიერება გჭირდებათ, რა რესურსები უნდა) და ხშირია დიზაინის साक්ষাৎকრებში.

## რატომ მნიშვნელოვანია შეფასება

```text
Estimating scale informs DESIGN decisions:
  → how many servers? how much storage? what database? do you need sharding/caching?
  → understanding the SCALE (small vs massive) shapes the whole design
→ rough numbers guide whether/how to scale (don't over- or under-engineer)
```

## რა უნდა შეფასოთ (ხელიერი გაანგარიშება)

```text
✓ TRAFFIC → users, requests/sec (QPS); read vs write ratio (e.g. 100:1 reads:writes)
  → peak vs average (design for peak); daily active users → requests
✓ STORAGE → data size per item × volume × growth over time → total storage (and growth rate)
✓ BANDWIDTH → data transferred per second (request size × QPS)
✓ MEMORY → cache size needed (e.g. cache the hot 20% of data)
→ rough estimates (order of magnitude) → good enough to inform design
```

## სასარგებლო რიცხვები და მიდგომა

```text
→ Know rough "latency numbers": memory ~ns, SSD ~µs, network/disk ~ms, cross-region ~100ms
→ Round numbers; use powers of 10; estimate, don't seek precision
→ Example: 1M daily users × 10 requests = 10M/day ≈ ~115 req/sec average (× peak factor)
→ derive resource needs from the estimates → justify the architecture
→ CAPACITY PLANNING → provision for expected load + growth + headroom; plan to scale
```

## რატომ მნიშვნელოვანია

მასშტაბის შეფასების და ტევადობის დაგეგმვის გაცნობიერება ღირებული უფროსი დონის ცოდნაა, რადგან **შეფასება ეხმარება სისტემის დიზაინის გადაწყვეტილებებში** და ეს დიზაინის სამუშაოს და ინტერვიუების საერთო ნაწილია, ამიტომ სასარგებლო, პრაქტიკული უნარია.

მასშტაბის შეფასება — მოსალოდნელი დატვირთვის, მონაცემების მოცულობისა და რესურსების საჭიროების გამოთვლა უხეშ "ხელიერ" გაანგარიშებებით — მნიშვნელოვანია, რადგან **სკალა განსაზღვრავს მთელ დიზაინს**: თუ იცით, რომ სისტემა ატარებს ათასობით ან მილიარდობით მოთხოვნას, განსაზღვრავს რამდენი დაგვჭირდება გაძლიერება, რა მონაცემთა ბაზები გამოვიყენოთ, და თუ საჭირო იქნება sharding და caching, რაც ხელს შეუწყობს უზედმეტი ინჟინერიის თავიდან აცილებას (არასაჭირო სირთულე მცირე სკალისთვის) და არასაკმარისი ინჟინერიის თავიდან აცილებას (დიზაინი, რომელიც ვერ справляется რეალურ დატვირთვასთან).

**რა უნდა შეფასოთ** — **ტრაფიკი** (მომხმარებლები, მოთხოვნა/წმ, წაკითხვა/ჩაწერის თანაფარდობა, პიკი vs საშუალო), **ხანგრძლივობა** (მონაცემების ზომა და ზრდა), **სიგანე** და **მეხსიერება/ქეშ** საჭიროებები — უზრუნველყოფს ჩარჩო სისტემის ზომის მოთავსებისთვის.

**მიდგომის** გაცნობიერება — უხეშ ლატენციის რიცხვების ცოდნა (მეხსიერება vs SSD vs ქსელი vs კროს-რეგიონი), მრგვალი რიცხვებისა და 10-ის ხარისხების გამოყენება, სიდიდის რიგის შეფასება სიზუსტის მაგივრად, რესურსების საჭიროების გამოთვლა შეფასებებიდან არქიტექტურის გამართლების მიზნით, და **ტევადობის დაგეგმვა** (მოწვევა მოსალოდნელი დატვირთვისთვის პლუს ზრდა და თავსივიანობა) — აჩვენებს მდგენელი უნარის პრაქტიკულ მხარეს სწრაფი შეფასებების გაკეთებაში.

ეს საერთო, მოსალოდნელი უნარია სისტემის დიზაინის ინტერვიუებში (სადაც ხელიერი შეფასება ემონстრაციას გაუწევს თქვენი უნარი მიზეზი გადაწყვიტოთ სკალის შესახებ) და რეალურ ტევადობის დაგეგმვაში.

კიდეგ სკალის შეფასება ეხმარება ძირითადი დიზაინის გადაწყვეტილებებში (როგორ გაძლიერება, რა რესურსები უნდა, უზედმეტი/საკმარისი ინჟინერიის თავიდან აცილება) და ეს დიზაინის სამუშაოს და ინტერვიუების საერთო ნაწილია, და რადგან **რა უნდა შეფასოთ** და **როგორ** (ხელიერი გაანგარიშება, ლატენციის რიცხვები, ტევადობის დაგეგმვა) — პრაქტიკული უნარია, მასშტაბის შეფასების და ტევადობის დაგეგმვის გაცნობიერება ღირებული უფროსი დონის ცოდნაა — სასარგებლო, მოსალოდნელი უნარი სისტემის დიზაინისთვის, რომელიც აინფორმაციებს არქიტექტურულ გადაწყვეტილებებს უხეშ რაოდენობრივი მიზეზით, საერთო რეალურ ტევადობის დაგეგმვასა და დიზაინის ინტერვიუებში, და აჩვენებს თქვენი უნარი დიზაინების დამტკიცებას რეალისტური მასშტაბის და რესურსების საჭიროების შეფასებებში.