---
title: 'API Ağ Geçidi'
source: 'https://academia.sh/tr/kurslar/trafik-katmani/api-ag-gecidi'
course: 'Trafik Katmanı'
language: tr
updated: '2026-08-17T18:11:02+00:00'
license: 'CC BY-SA 4.0'
---

# API Ağ Geçidi

Kenarda biriken sorumlulukların yerleştirilmesi: API ağ geçidinin yük dengeleyiciden ve ters vekilden hangi kararla ayrıldığı, beş kenar sorumluluğunun üç yerleşimde tekrarlanan satır ve düzenlenen birim sayısıyla ölçülmesi ve tek giriş noktasının uçtaki tepe istek hızını tek bileşende topladığının hesaplanması.

Önceki konu isteğin **hangi kopyaya** düştüğünü çözdü. Yük dengeleyici bir yönlendirme
aygıtıdır: kararını bağlantı düzeyinde ya da isteğin içeriğine bakarak verir, düşen kopyayı
sağlık denetimiyle havuzdan çıkarır ve durum kopyanın belleğinde kaldığında seçme yetkisini
kaybeder — oturum yapışkanlığı bunun bedelini gereken kopya sayısının 3'ten 4'e çıkmasıyla
ölçtü. Kararın konusu her seferinde aynıydı: eldeki eş kopyalardan hangisi.

Kenarda biriken işler bundan fazlasıdır. Bir takip isteği uygulamaya ulaşmadan önce
kimliğinin doğrulanması, hızının sınırlanması, gövdesinin servisin beklediği biçime
çevrilmesi ve birden çok servisten gelen yanıtın tek gövdede toplanması gerekebilir.
Bunların hiçbiri "hangi kopya" sorusu değildir ve üç yere birden konabilir: dengeleyiciye,
uygulamaya ya da ayrı bir katmana. Bu ders üçüncü seçeneği adlandırır ve soruyu tek bir
yerleşim kararına indirir: her serviste mi, kenarda tek bir bileşende mi, ikisine bölünmüş mü.

## Ağ Geçidi Hangi Kararı Verir

**API ağ geçidi** (API gateway), bir sistemin dışa açılan tek giriş noktasıdır ve kararını
*işlem* düzeyinde verir: gelen istek hangi servise ait, hangi biçimde iletilecek, hangi
denetimlerden geçmiş olması gerekiyor. Bu kararı verebilmek için ağ geçidi bir **servis
haritası** taşır — yolların servislere eşlenişi.

Yük dengeleyicinin kararı bu değildir. Dengeleyici, aynı işi yapan kopyalar arasından birini
seçer; hangi servisin ne yaptığını bilmesi gerekmez, elindeki havuzun eş olduğunu varsayar.
Ters vekil ise Sunucu Tarafı Temelleri kursunda kurulan biçimiyle isteği alıp arkadaki
sunucuya ileten süreçtir; TLS sonlandırma ve statik dosya sunumu orada ele alındı. Üç adın
aynı süreçte birleşmesi sıktır ve bu bir çelişki değildir: ayrım süreçlerin sayısında değil,
verilen kararda durur. Bir istek için "hangi kopya" sorusu dengeleyicinin, "hangi servis ve
hangi biçim" sorusu ağ geçidinin kararıdır.

Bu ayrım ağ geçidinin **ne yapmaması** gerektiğini de belirler. Ücretlendirme bağlamının
tarife kuralı ya da teslimat operasyonu bağlamının rota kuralı ağ geçidine konduğunda, kenar
iki bağlamın alan kurallarını birden tanımaya başlar ve iki bağlamın her değişikliği kenarı
düzenletir. Kenara ait olan iş, isteğin **üstverisine** bakarak karar verilebilen iştir;
gönderinin kendisine bakmayı gerektiren iş servistedir. Bu ölçüt konunun üçüncü dersinde
mekanik bir kurala çevrilir.

## Beş Sorumluluk, Üç Yerleşim

Ölçüm için süreç içi bir model kullanılır: gerçek bir ağ geçidi ürünü, ayrı süreç ya da ağ
yoktur. Model üç servisi (takip, olay, ücret — sırasıyla okuma, yazma ve toplu akış) ve beş
kenar sorumluluğunu bir veri yapısı olarak tutar. Belirteç doğrulama Kimlik Doğrulama ve
Yetkilendirme kursunda, hız sınırlama Web API Tasarımı kursunda kurulmuştu; burada ikisinin
de algoritması değil **yeri** ele alınır.

```js
// kenar/yerlesim.mjs — uc servis, bes kenar sorumlulugu ve uc yerlesim; surec ici model
export const SERVIS = { takip: "okuma", olay: "yazma", ucret: "toplu" };

// Her sorumlulugun gerceklestirmesi kac satir tutuyor (model degeri, tek yerde yazili)
export const SORUMLULUK = {
  "yol eslesme": 7,
  "belirtec dogrulama": 12,
  "hiz sinirlama": 9,
  "istek gunlugu": 6,
  "bicim cevirisi": 11,
};

export const YERLESIM = {
  "her serviste": { gecit: [], serviste: Object.keys(SORUMLULUK) },
  "ag gecidinde": { gecit: Object.keys(SORUMLULUK), serviste: [] },
  "karma": {
    gecit: ["yol eslesme", "hiz sinirlama", "istek gunlugu", "belirtec dogrulama"],
    serviste: ["belirtec dogrulama", "bicim cevirisi"],
  },
};

export function olc(y) {
  const servisSayisi = Object.keys(SERVIS).length;
  const toplam = (liste) => liste.reduce((t, s) => t + SORUMLULUK[s], 0);
  const gecitVar = y.gecit.length > 0;
  return {
    "istemcinin bildigi adres": gecitVar ? 1 : servisSayisi,
    "kenarda toplanan satir": toplam(y.gecit),
    "servislerde tekrarlanan satir": servisSayisi * toplam(y.serviste),
    "sorumlulugu tasiyan birim (ortalama)":
      Number((Object.keys(SORUMLULUK).reduce((t, s) =>
        t + (y.gecit.includes(s) ? 1 : 0) + (y.serviste.includes(s) ? servisSayisi : 0), 0)
        / Object.keys(SORUMLULUK).length).toFixed(2)),
    "bir istegin doktugu durak": gecitVar ? 2 : 1,
    "ag gecidinin doktugu akis": gecitVar ? servisSayisi : 0,
    "gecit durdugunda yanitlanan akis": `${gecitVar ? 0 : servisSayisi}/${servisSayisi}`,
  };
}
```

Satır sayıları modelin girdisidir ve **varsayım** sınıfındadır: bir gerçekleştirmeden
ölçülmemiştir, yalnız büyüklük sırasını taşır. Okunan şey toplamın kendisi değil, üçe
çarpılmasının ürettiği farktır; beş sayı yarıya inse de tekrarlanan satırın kenarda toplanan
satıra oranı aynı kalır.

Üçüncü yerleşimde `belirtec dogrulama` iki listede birden geçiyor. Bu bir yazım hatası
değil, bilinçli bir seçimdir: ağ geçidi belirteci doğrular, servis de doğrular ve ikinci
doğrulama ağ geçidinin atlandığı durumu karşılar. Sayaç bunu ödenen bir sayı olarak
gösteriyor.

```js
// kenar/olc.mjs — uc yerlesimi ayni sayaclarla olcer ve K01 hesabina baglar
import { YERLESIM, olc } from "./yerlesim.mjs";

const ALAN = ["istemcinin bildigi adres", "kenarda toplanan satir",
  "servislerde tekrarlanan satir", "sorumlulugu tasiyan birim (ortalama)",
  "bir istegin doktugu durak", "ag gecidinin doktugu akis",
  "gecit durdugunda yanitlanan akis"];

const olcum = Object.entries(YERLESIM).map(([ad, y]) => ({ ad, ...olc(y) }));
console.log(`${"olcu".padEnd(37)}${olcum.map((o) => o.ad.padStart(14)).join("")}`);
for (const a of ALAN) {
  console.log(`${a.padEnd(37)}${olcum.map((o) => String(o[a]).padStart(14)).join("")}`);
}

// K01 Kabaca Buyukluk Hesabi dersinin sayilari (hesap sinifi, oradan alindi)
const K01 = { okumaTepe: 416.67, yazmaTepe: 97.22, ucTepe: 513.89 };
const yaz = (ad, deger, not = "") => console.log(`${ad.padEnd(37)}${deger.padStart(10)}  ${not}`);

console.log("");
yaz("K01 — uctaki tepe istek/s", K01.ucTepe.toFixed(2), "okuma 416.67 + yazma 97.22");
yaz("gecit yok — en yuklu bilesen", K01.okumaTepe.toFixed(2), "takip servisi");
yaz("gecit var — en yuklu bilesen", K01.ucTepe.toFixed(2),
  `ag-gecidi, x${(K01.ucTepe / K01.okumaTepe).toFixed(2)}`);
for (const o of olcum) {
  yaz(`durak-istek/s — ${o.ad}`,
    (K01.ucTepe * o["bir istegin doktugu durak"]).toFixed(2),
    `durak ${o["bir istegin doktugu durak"]}`);
}
```

```
olcu                                   her serviste  ag gecidinde         karma
istemcinin bildigi adres                          3             1             1
kenarda toplanan satir                            0            45            34
servislerde tekrarlanan satir                   135             0            69
sorumlulugu tasiyan birim (ortalama)              3             1             2
bir istegin doktugu durak                         1             2             2
ag gecidinin doktugu akis                         0             3             3
gecit durdugunda yanitlanan akis                3/3           0/3           0/3

K01 — uctaki tepe istek/s                513.89  okuma 416.67 + yazma 97.22
gecit yok — en yuklu bilesen             416.67  takip servisi
gecit var — en yuklu bilesen             513.89  ag-gecidi, x1.23
durak-istek/s — her serviste             513.89  durak 1
durak-istek/s — ag gecidinde            1027.78  durak 2
durak-istek/s — karma                   1027.78  durak 2
```

## Sayıların Okunması

Tablonun ilk üç satırı ağ geçidinin ne için kurulduğunu söylüyor. Geçit yokken istemci üç
adres bilmek zorunda ve beş sorumluluk üç serviste 135 satır tutuyor; geçitle birlikte adres
1'e, o satırlar kenarda 45'e iniyor. Aynı işi taşıyan satır sayısı üçte bire düşmüyor —
sıfırdan 45'e çıkıyor ve 135 sıfırlanıyor. Fark, tekrarın kaldırılmasıdır: bir sorumluluğu
taşıyan birim sayısı ortalama 3'ten 1'e iniyor, yani hız sınırlama kuralı değiştiğinde
düzenlenen birim sayısı 3 yerine 1 oluyor.

Sonraki üç satır bedeli veriyor. Her istek artık iki durağa dokunuyor; uçtaki tepe hız
sabit kalsa bile sistemde saniyede işlenen durak-istek sayısı 513,89'dan 1027,78'e, tam iki
katına çıkıyor. Bu sayı gecikme değildir — bir süre ölçülmedi — ama gecikmenin nereden
büyüyeceğini gösterir: her istek fazladan bir bileşenin kuyruğuna girer.

Son satır en pahalısıdır. Geçit durduğunda yanıtlanan akış 3/3'ten 0/3'e iniyor. Geçitsiz
yerleşimde bir servisin durması yalnız o akışı düşürürken, geçitli yerleşimde tek bir
bileşen üç akışı birden düşürüyor. Karma yerleşim bu satırı düzeltmiyor: belirteci iki yerde
doğrulamak ağ geçidinin atlanabildiği durumu karşılar, ağ geçidinin durduğu durumu
karşılamaz. Karma yerleşimin gerçek kazancı ortada duruyor — tekrarlanan satır 135 yerine
69, kenarda toplanan satır 45 yerine 34 — ve gerçek bedeli de: bir sorumluluğu taşıyan birim
sayısı ortalama 2, yani sorumlulukların yarısı hâlâ iki yerde bakılır.

## Hesaba Dönüş

Kursun kuralı gereği bu kararın K01 hesabındaki karşılığı yazılır. Kabaca Büyüklük Hesabı
dersinde uçtaki tepe istek hızı saniyede 513,89 çıkmıştı (416,67 okuma + 97,22 yazma) ve o
sayı **üç ayrı uca** dağılmış hâlde duruyordu; o dersin diyagramında en yüklü kenar 416,67
istek/s taşıyan takip kenarıydı. Ağ geçidi kurulduğunda bu dağılım kalkıyor: tek bir bileşen
513,89 istek/s taşıyor, yani eski en yüklü bileşenin 1,23 katı.

Daha önemlisi, ağ geçidinin dokunduğu akış sayısı 3 oluyor. Sistem Tasarımı Nedir dersinde
bu sayı yalnız `gonderi-deposu` için 3'tü ve o ders bir kural bırakmıştı: bir tasarımın en
kırılgan noktası, en çok akışın dokunduğu bileşendir. Ağ geçidi kurulduğunda sistemde böyle
iki bileşen olur — biri veri katmanında, biri kenarda. Kenar bileşeni için bu, `gecit
durdugunda yanitlanan akis` satırının 0/3 olmasıyla aynı olgudur.

Hesabın değişmeyen yanı da yazılmalı: `onbellek arkasi okuma/s` 41,67, `okuma cikis Mbit/s`
1,60 ve günlük veri artışı 976 MB bu kararla oynamıyor. Ağ geçidi bu dersteki hâliyle istek
başına gövdeyi değiştirmiyor, yalnız isteğin geçtiği durak sayısını ve sorumlulukların yerini
değiştiriyor. Gövdeyi değiştiren kararlar sonraki iki derste ölçülür.

## Özet

- API ağ geçidi kararını işlem düzeyinde verir ve bir servis haritası taşır; yük dengeleyici
  eş kopyalar arasından seçer, ters vekil isteği iletir. Üçü aynı süreçte birleşebilir, ayrım
  verilen karardadır.
- Kenara ait iş, isteğin üstverisine bakarak karar verilebilen iştir; gönderinin kendisine
  bakmayı gerektiren alan kuralı serviste kalır.
- Beş sorumluluk üç serviste 135 satır tekrarlanırken kenarda 45 satıra iniyor ve bir
  sorumluluğu taşıyan birim sayısı ortalama 3'ten 1'e düşüyor.
- Ödenen sayılar: her istek 1 yerine 2 durağa dokunuyor (durak-istek/s 513,89 → 1027,78) ve
  geçit durduğunda yanıtlanan akış 3/3'ten 0/3'e iniyor.
- Karma yerleşim ortada duruyor: tekrarlanan satır 69, kenarda toplanan satır 34, ama
  sorumluluk başına birim sayısı ortalama 2 ve 0/3 satırı düzelmiyor.
- K01'e dönüş: uçtaki 513,89 istek/s üç kenara dağılmış hâlden tek bileşene toplanıyor (eski
  en yüklü bileşenin 1,23 katı) ve ağ geçidinin dokunduğu akış sayısı 3 oluyor.

## Sonraki Adım

Bu ders ağ geçidinin taşıdığı servis haritasını bir varsayım olarak kullandı: yolların
servislere eşlendiği söylendi, eşlemenin kendisi ölçülmedi. Eşleme ise iki ayrı iş yapabilir.
Birincisi yönlendirmedir — gelen yol tek bir servise çevrilir ve istemci arkadaki bölünmeyi
görmez. İkincisi daha fazlasıdır: takip sayfası hem gönderinin durumunu hem ücretini
istiyorsa, ağ geçidi tek isteği iki servise dağıtıp iki yanıtı tek gövdede birleştirebilir.
Sonraki ders bu ikisini gerçek yerel süreçlerle kurar ve toplamanın istemci istek sayısını
kaç düşürdüğünü, karşılığında uçtaki gövdeyi kaç bayt büyüttüğünü ölçer.
