Scalability Patterns, דפוסי סקיילביליטי

למה Scalability היא לא רק 'עוד שרתים'

AppsFlyer, שמשרדיה בתל אביב, מעבדת נתוני 5 מיליארד מכשירים בזמן אמת. Wix מגישה 230 מיליון אתרים לגולשים בכל רגע נתון. monday.com מנהלת workloads של 186 אלף ארגונים בו-זמנית. אף אחת מהחברות האלה לא הגיעה לשם 'סתם', כל order of magnitude דרש שינוי ארכיטקטוני מחושב.

ההנחה הנפוצה היא שscalability = יותר שרתים. זאת טעות. Scalability אמיתית היא היכולת של המערכת לעבוד טוב יותר כשמוסיפים resources, ולשם כך צריך design מכוון מהיום הראשון. Martin Kleppmann מנסח את זה ב-DDIA: "scalability is not a one-dimensional label, it is a set of questions about how the system handles growth."

בשיעור זה נבין את הpatterns שפותרים כל שלב, ואיך Claude הופך לשותף חשיבה מצוין לכל scaling decision.

ה-4 שלבי Scaling, ומה משתנה בכל אחד

Scale	הבקבוק הצר הראשון	הפתרון המינימלי
100 משתמשים	אין בעיה	שרת יחיד, SQLite, deploy מהיר
100K משתמשים	DB bottleneck, slow queries	Read replicas, Redis cache, indexes
1M משתמשים	Max connections ל-DB יחיד	DB sharding, CDN, async queues
10M+ משתמשים	Multi-region latency, write hotspots	Global load balancing, event-driven architecture

Horizontal vs Vertical Scaling, ההחלטה שאף אחד לא מסביר נכון

Vertical scaling (גדילה כלפי מעלה) אומר מכונה גדולה יותר, יותר CPU, יותר RAM. פשוט, מהיר, אבל יש תקרה. מעבר לתקרה, הבעיה היא גם כספית: מכונה של 64 cores עולה לא פי 4 ממכונה של 16 cores.

Horizontal scaling (גדילה לרוחב) אומר יותר מכונות קטנות. מצריך stateless design, כל שרת צריך להיות מסוגל לטפל בכל request ללא תלות בשרת אחר. Load balancer מפנה traffic, session state עוברת ל-Redis, והמערכת יכולה לצמוח ללא הגבלה תיאורטית.

המציאות ב-2025-2026: רוב הסטארטאפים הישראליים מוצאים את עצמם עם Kubernetes HPA שמבצע autoscaling אוטומטי, טשטוש הגבול בין שתי הגישות. אבל ה-stateless requirement נשאר קריטי: אפליקציה שמאחסנת session state ב-memory של שרת לא ניתנת ל-horizontal scaling.

Caching, 4 שכבות, 4 בעיות שונות

caching טוב הוא לא "שים Redis ותגמור", זה מדע של לדעת איפה לשים cache ולמה. ארבע השכבות:

Browser Cache: static assets, CDN headers. הכי זול, client לא מגיע לשרת בכלל.
CDN (Cloudflare, Akamai, Fastly): תוכן גיאוגרפי קרוב ל-user. Wix חסכה 45% בעלויות ו-latency ירדה מ-18ms ל-2ms בעזרת שינוי שכבת ה-cache.
Application Cache (Redis): session data, computed results, API responses יקרים. כאן cache stampede קורה.
DB-level (PgBouncer, prepared statements): connection pooling מקטין overhead של connection creation. טריידאוף: PgBouncer ב-transaction mode לא תומך ב-prepared statements ו-session-level features.

hit rate מתחת ל-80% הוא דגל אדום, בדרך כלל אומר TTL קצר מדי, cache keys לא עקביים, או שהנתון שמגיע מה-DB לא עובר caching כלל.

Sharding, מה אף אחד לא אומר לך לפני שמתחילים

sharding מחלק את ה-DB לחלקים (shards) על שרתים שונים. הבחירה הכי קריטית: shard key. ברגע שבחרת, קשה מאוד לשנות.

Hash sharding על user_id: טוב ל-point lookups (90% מהreads), גרוע ל-range queries.
Range sharding על timestamp: טוב ל-time-series, יוצר hotspot (כל הwrites הולכים ל-shard הנוכחי).
Geographic sharding: טוב ל-data sovereignty (GDPR, חוק הפרטיות הישראלי), גרוע ל-cross-region queries.
Consistent Hashing: כשמוסיפים node, רק K/N keys צריכים להיות remapped (במקום כמעט הכל). מאפשר elastic scaling בלי cache storm.

עצת engineers ב-r/ExperiencedDevs: "הדבר הכי קשה ב-sharding הוא לא המיגרציה הראשונה, זה כל feature שבונים אחר כך שצריך לחשוב איזה shard להכנס אליו."

הסבר לי שארדינג

Design a sharding strategy for an Israeli B2B SaaS platform with 500K teams. Query patterns: team dashboard lookup by team_id (85% of reads), cross-team analytics by date range (10%), search by tag (5%). Compare hash sharding on team_id vs range sharding on created_at vs geographic (IL/EU/US), for each: query efficiency, hotspot risk, rebalancing complexity when adding shards. Recommend best approach given that we have 6 engineers and cannot afford 3-month migrations.

Little's Law, הכלי שמנהלי מוצר ו-CTOs לא מכירים

Little's Law: L = lambda * W. מספר הbקשות במערכת = קצב ההגעה כפול זמן הtreating. המסקנה המעשית: אם latency גדלה פי 2, אתה צריך פי 2 שרתים כדי לשמור על אותו throughput, גם אם load לא השתנה. Claude יכול לחשב capacity planning מלא: תן לו target RPS + p99 latency target + מה כל שרת מסוגל לעשות.

יותר מדי keys ב-Redis

TTL קצר מדי או cache keys לא עקביים בין שרתים

בעיית network latency לשרת ה-Redis

שרת Redis יחיד לא מספיק

אי-עקביות בנתונים בין DB nodes

הוספת שרת גורמת לremapping של כמעט כל ה-keys ולcache storm

replication factor לא מחושב נכון

Read/write splitting לא עובד

כדי לחשב צריך למדוד מספר ה-CPU cores בכל שרת

אם latency גדלה, צריך פחות שרתים

אם latency גדלה פי 2, צריך פי 2 שרתים לאותו throughput

הנוסחה חלה רק על DB queries, לא על שרתי API

3 טעויות נפוצות

Premature Sharding: Engineers רבים עוברים לsharding ב-100K משתמשים כשread replica אחד + Redis היו מחזיקים עד 5M. Sharding מוסיף complexity לכל feature חדש, שווה להישאר מהיר כמה שניתן.
Cache Stampede: כשhit rate יורד (deployment, cache flush), כולם מגיעים ל-DB בבת אחת. הפתרון: probabilistic early expiration, או mutex לocking עם Redis SETNX, רק process אחד מחשב, השאר מחכים.
שכחת את ה-Write Path: כולם מדברים על read scaling (replicas, CDN, cache). אבל ב-write-heavy applications כמו IoT, logging, analytics, הwrite path הוא הבקבוק האמיתי. כאן Kafka, Cassandra, או time-series databases נכנסים לתמונה.

איך Claude עוזר לחשוב על Scaling

Claude Opus 4.7 עם 1M token context window מאפשר להזין ארכיטקטורה שלמה, ERD, code, infra diagrams, ולקבל ניתוח scaling מפורט בפגישה אחת. שלושה prompts שעובדים:

Scaling Roadmap: "אנחנו CTO של SaaS ישראלי עם X משתמשים. DB ב-80% CPU. תן לי תוכנית scaling ל-3 שלבים, שינוי מינימלי בכל שלב, ללא over-engineering."
Shard Key Decision: "Compare [3 sharding strategies] for [my system] with these query patterns: [list]. Give me a decision matrix: query efficiency / hotspot risk / rebalancing cost."
Capacity Planning: "My API target: 10,000 RPS, p99 latency 200ms, each server handles 50 concurrent requests. Calculate: how many servers, memory needed, and what happens if latency doubles."

הכוח של Claude כאן הוא לא בתשובות הטכניות בלבד, הוא מאלץ לנסח את הbottleneck במדויק. Engineers רבים מגלים שהניסוח עצמו מבהיר להם מה הבעיה האמיתית.