0Pricing
API Rate Limiting & Scalability Patterns · Ders

Yatay ve Dikey Ölçeklendirme

Bir API'ye kapasite eklemenin iki temel yolunu — ölçeği büyütme ve ölçeği genişletme — anlayın; maliyet, sınırlar ve mimariye göre aralarında seçim yapmayı öğrenin.

Yatay ve Dikey Ölçeklendirme, CoddyKit'te ücretsiz bir API Rate Limiting & Scalability Patterns dersidir. Bu, 4 dersinin 4. dersidir. Aşağıdan dersin tamamını ücretsiz okuyabilir, sonra tarayıcıda yerleşik kod editörü ve 7/24 yapay zeka koçu ile uygulamalı olarak pratik yapabilirsin. Bu, API Rate Limiting & Scalability Patterns öğrenme yolunun bir parçasıdır ve ilerlemeniz web ve CoddyKit uygulaması arasında senkronize olur. API Rate Limiting & Scalability Patterns kursu toplamda 4 dersten oluşur.

Bu dersin bazı bölümleri henüz çevrilmemiş olup İngilizce olarak gösterilmektedir.

Two Ways to Grow

When an API runs out of capacity you have two levers:

  • Vertical scaling (scale up) — make the machine bigger
  • Horizontal scaling (scale out) — add more machines

Each has very different cost and reliability profiles.

Vertical Scaling Explained

Vertical scaling means upgrading a single server: more CPU cores, more RAM, faster disks.

It is simple — no code changes — but you eventually hit the largest instance available, and that one box is a single point of failure.

Horizontal Scaling Explained

Horizontal scaling adds more identical servers behind a load balancer. Traffic spreads across the fleet.

  • No hard ceiling — add nodes as needed
  • One node failing does not take down the service

The Cost Curve

Vertical scaling cost rises steeply — top-tier hardware carries a premium. Horizontal scaling uses many commodity nodes, which is usually cheaper per unit of capacity at large scale.

Statelessness Enables Scale-Out

To scale out, any node must handle any request. That requires stateless services — no session data stored on the instance.

Push session and state to a shared store (Redis, a database) so nodes stay interchangeable.

// session in a shared store, not local memory
await redis.set('session:' + id, data, 'EX', 3600)

Auto-Scaling Groups

Cloud platforms add or remove nodes automatically based on metrics like CPU or request rate.

You define a min, max, and a target metric; the platform keeps the fleet sized to load.

min_instances: 2
max_instances: 20
target_cpu_percent: 60

When Vertical Still Wins

Scaling up is the right call when:

  • The workload is hard to distribute (a single large in-memory dataset)
  • You need a quick fix before re-architecting
  • Licensing is per-node and a bigger box is cheaper

Diminishing Returns

Adding nodes is not free scaling — shared resources (a single database, a lock) become the new bottleneck. This is why scaling the data tier often matters more than the app tier.

Combining Both

Real systems mix strategies: right-size each node (a bit of vertical) then run many of them (horizontal). The goal is the best cost per request at your reliability target.

Measuring Before Scaling

Never scale blindly. Profile first to find the real constraint — CPU, memory, I/O, or a downstream dependency. Scaling the wrong dimension wastes money and hides the true bottleneck.

Scaling and Cost Awareness

Capacity is not free. A fleet sized for peak sits idle at night, burning money. Combine auto-scaling with right-sizing and consider spot or reserved capacity to match spend to real demand.

Quick Check

Check your understanding of scaling directions.

Recap

You compared scaling strategies:

  • Vertical — bigger box, simple, but capped and a single point of failure
  • Horizontal — more boxes, resilient, needs statelessness
  • Auto-scaling sizes the fleet to load
  • Always measure the real bottleneck first

Sıkça Sorulan Sorular

“Yatay ve Dikey Ölçeklendirme” dersi ücretsiz mi?

Evet — “Yatay ve Dikey Ölçeklendirme” dersin tüm metni burada web'de ücretsiz olarak okunabilir. Etkileşimli olarak pratik yapmak (yerleşik kod editörü ve 7/24 yapay zeka koçu) ve API Rate Limiting & Scalability Patterns kursunun geri kalanını açmak için CoddyKit PRO'ya yükselt. API Rate Limiting & Scalability Patterns kursu toplamda 4 dersten oluşur.

“Yatay ve Dikey Ölçeklendirme” dersinde ne öğreneceğim?

Bir API'ye kapasite eklemenin iki temel yolunu — ölçeği büyütme ve ölçeği genişletme — anlayın; maliyet, sınırlar ve mimariye göre aralarında seçim yapmayı öğrenin. API Rate Limiting & Scalability Patterns ile uygulamalı kodu tarayıcıda doğrudan çalıştırarak pratik yaparsın ve 7/24 yapay zeka koçu dersi çalışırken sorularını yanıtlar.

API Rate Limiting & Scalability Patterns öğrenmeye başlamak için deneyim gerekli mi?

Önceden deneyim gerekmez. CoddyKit'te API Rate Limiting & Scalability Patterns, başlangıçtan ileri seviyeye kadar yapılandırıldığı için buradan başlayabilir veya başından başlayıp kendi hızında ilerleme yapabilirsin. Bu, 4 dersinin 4. dersidir.

“Yatay ve Dikey Ölçeklendirme” dersi ne kadar sürer?

Çoğu CoddyKit dersi yaklaşık 5–10 dakika sürer. Her biri kısa ve etkileşimli olduğu için sabit ilerleme yaparsın ve web ile uygulama arasında tam olarak bıraktığın yerden devam edebilirsin.

Bu API Rate Limiting & Scalability Patterns dersinde kod yazıp çalıştırabilir miyim?

Evet. Her API Rate Limiting & Scalability Patterns dersi yerleşik bir kod editörü içerir, bu sayede tarayıcıda gerçek kod yazıp çalıştırabilir ve anlık yapay zeka geri bildirimi alırsın — yerel kurulum gerekli değildir.

Bu kursun tüm dersleri

  1. API Ölçeklenebilirliğini Anlama
  2. Temel Ölçeklenebilirlik Ölçütleri
  3. Durumsuz ve Durum Bilgili API Tasarımı
  4. Yatay ve Dikey Ölçeklendirme
← API Rate Limiting & Scalability Patterns Sayfasına Dön