AI API Ağ Geçidinde Hizmet Katmanı Yönlendirmesi: Sabit Kodlama Sağlayıcıları Olmadan Hızlı, Standart, Tedarik Edilmiş ve Toplu

Hizmet katmanı yönlendirme, bir yapay zeka isteğinin premium düşük gecikmeli kapasiteyi, normal isteğe bağlı kapasiteyi, ayrılmış aktarım hızını veya indirimli eşzamansız işlemeyi hak edip etmediğine karar veren politika katmanıdır. Bu katman olmadan uygulama ekipleri genellikle sağlayıcıya özel işaretleri, dağıtım adlarını ve toplu uç noktaları doğrudan ürün kodunda kodlar. Bu, gecikmenin, maliyetin, kotanın ve kiracının faturalandırma davranışının yönetilmesini zorlaştırır.

Ağ geçidi, sağlayıcı mekanizmalarını değil, iş yükünün amacını açığa çıkarmalıdır. Bir ürün ekibi "bu etkileşimli bir destek yanıtıdır" veya "bu gecelik bir zenginleştirme işidir" diyebilmeli, ağ geçidi ise niyeti doğru yukarı akış kapasite seçeneğine eşleştirip gerçekte ne olduğunu kaydedebilmelidir.

Okuyucu sorunu: kapasite sınıfları uygulama mantığı haline geliyor

Birden fazla model sağlayıcı kullanan ekipler genellikle basit model yönlendirmeyle başlar: Bu model kimliğini bu sağlayıcıya gönderin. Sağlayıcılar farklı kapasite sınıflarını kullanıma sunduğunda yönlendirme zorlaşır:

• Kullanıcıya yönelik yollar için premium, düşük gecikmeli istek işleme.
• Sıradan eşzamanlı trafik için standart paylaşılan kapasite.
• Tahmin edilebilir aktarım hızı için ayrılmış veya temel hazırlığı yapılmış kapasite.
• Gecikmeye toleranslı iş yükleri için toplu veya eşzamansız API'ler.
• Ayrılmış kapasite tükendiğinde yayılma davranışı.

Bu seçimleri her uygulama kendisi yaparsa kuruluş dört şey üzerindeki kontrolünü kaybeder: premium kapasiteyi kimin kullanabileceği, maliyeti ne kadar, kapasite kullanılamadığında ne olacağı ve seçilen katmanın ürünü harcamayı haklı çıkaracak kadar geliştirip geliştirmediği.

Pratik model, AI API ağ geçidinin içine sağlayıcıdan bağımsız bir hizmet kalitesi katmanı yerleştirmektir.

Değerlendirilecek gerçekler

Ayrıntılar sağlayıcıya göre değişir ancak gözlemlenebilir birçok gerçek, ağ geçidi düzeyinde bir tasarımı destekler.

• Gerçek: Bazı sağlayıcılar, premium işleme için istek başına hizmet katmanı sunar. OpenAI, service_tier parametresini kullanan Hızlı modu istek başına bir seçenek olarak tanımlar ve bunun Standart işleme göre premium olarak faturalandırıldığını belirtir. OpenAI ayrıca, Öncelikli işlemenin 30 Temmuz 2026'da Hızlı mod olarak yeniden adlandırıldığını, hem service_tier=priority hem de service_tier=fast'nin API istek için kabul edildiğini belirtir.
• Gerçek: Premium isteklerinin işlenmesi ayrı bir kota evreni olmayabilir. OpenAI, Hızlı mod hız sınırlarının diğer hizmet katmanlarıyla paylaşıldığını ve hızlı trafik artışlarının, trafiğin bir kısmının Standart işlemeye gönderilebileceği artış hızı davranışını tetikleyebileceğini belirtiyor.
• Gerçek: Hizmet katmanı bir raporlama ve faturalandırma boyutu olabilir. OpenAI, API müşterilerinin Kullanım kontrol paneli verilerini hizmet katmanına ve satır öğesine göre gruplandırabileceğini söylüyor. Anthropic, API kullanım raporlamasında hizmet katmanı değerleri olarak standard, priority ve batch'yi belgeliyor.
• Gerçek: Toplu API'ler, eşzamansız çalışmanın maliyetini önemli ölçüde azaltabilir. Anthropic fiyatlandırma belgelerinde, Batch API'ın, giriş ve çıkış jetonlarında %50 indirimle eşzamansız büyük hacimli işlemeyi desteklediği belirtiliyor. Google'nin Gemini Toplu İş API belgeleri, bazı yüksek hacimli işler için 24 saate kadar geri dönüş ödünleşimleriyle birlikte, standart maliyetin %50'sindeki büyük eşzamansız iş yüklerini açıklamaktadır.
• Gerçek: Tedarik edilen aktarım hızı ayrı bir kapasite modelidir. Microsoft, kapasitenin paylaşıldığı ve üretimin talebe göre değişebileceği standart dağıtımların aksine, Azure OpenAI tarafından sağlanan aktarım hızını ayrılmış kapasite olarak belgelemektedir. Microsoft ayrıca aynı Azure OpenAI kaynağında sağlanan dağıtımlardan standart dağıtımlara yayılmayı da belgeliyor.

Öneri, her sağlayıcı teriminin uygulama koduna yansıtılmamasıdır. Öneri, bu mekanizmaları iş odaklı ağ geçidi katmanlarına göre normalleştirmektir.

Sağlayıcıdan bağımsız ağ geçidi katmanlarını tanımlayın

Katmanları satıcı terminolojisine göre değil, iş yükü davranışına göre adlandırarak başlayın. Yararlı bir ilk sınıflandırma şöyledir:

Ağ geçidi katmanı	Tipik iş yükü	Gecikme beklentisi	Maliyet duruşu	Varsayılan sürüm düşürme davranışı
interactive_fast	Ses döngüleri, canlı sohbet, yüksek değerli kullanıcı işlemleri	En düşük pratik gecikme	Premium'a izin veriliyor	İş akışına bağlı olarak standart şekilde ilerleyin veya hızlı başarısız olun
interactive_standard	Normal sohbet, taslak hazırlama desteği, dahili yardımcı pilotlar	Senkron	Varsayılan maliyet	Yeniden deneyin, geri dönün veya kontrollü bir hata döndürün
reserved_capacity	Sabit kullanımla öngörülebilir üretim trafiği	Tahmin edilebilir aktarım hızı	Ön ödemeli veya taahhütlü kapasite	Yalnızca politika izin verdiğinde yayılma
background_discount	Değerlendirmeler, zenginleştirme, özetleme, yerleştirmeler, raporlar	Eşzamansız	İndirim tercih edilir	Toplu yol mevcut olana kadar sıraya gir
emergency_fallback	Olay müdahalesi veya geçici müşteri üst kademesine iletme	Politikaya bağımlı	Kontrollü istisna	Onay penceresinden sonra süresi otomatik olarak dolacak

Bu seviye listesi kasıtlı olarak küçüktür. Yirmi katman oluşturursanız geliştiriciler sistemi atlayacaktır. Ağ geçidi yine de bir nötr katmanı dahili olarak sağlayıcıya özgü çeşitli mekanizmalarla eşleyebilir.

İstenen katmanı seçilen katmandan ayırın

Arayanın istenen katmanı göndermesi gerekir, ancak ağ geçidinin hem istenen katmanı hem de seçilen gerçek katmanı kaydetmesi gerekir. Bunlar her zaman aynı değildir.

Örnek istek meta verileri:

{
  "model": "support-chat-default",
  "messages": [...],
  "metadata": {
    "workflow": "customer_support_reply",
    "tenant_id": "tenant_123",
    "requested_gateway_tier": "interactive_fast",
    "end_user_id": "u_789"
  }
}

Örnek sevk kaydı:

{
  "request_id": "req_abc",
  "tenant_id": "tenant_123",
  "api_key_id": "key_live_456",
  "workflow": "customer_support_reply",
  "model_alias": "support-chat-default",
  "requested_gateway_tier": "interactive_fast",
  "selected_provider": "provider_a",
  "selected_provider_tier": "fast",
  "tier_outcome": "selected_as_requested",
  "downgrade_reason": null,
  "input_tokens": 1840,
  "output_tokens": 420,
  "latency_ms": 1420,
  "estimated_cost_usd": "0.0312",
  "settled_cost_usd": "0.0308"
}

Artış sınırları veya kiracı bütçe kuralları nedeniyle standart işlemeye bir prim isteği gönderilirse bu görünür olmalıdır:

{
  "requested_gateway_tier": "interactive_fast",
  "selected_provider_tier": "standard",
  "tier_outcome": "downgraded",
  "downgrade_reason": "tenant_premium_budget_exhausted"
}

Bu ayrım, yanıltıcı analizlerin önüne geçer. Kontrol panelleri yalnızca arayanın istediğini gösteriyorsa finans, prim amacını görecek ancak prim uygulamasını göremeyecektir. Kontrol panelleri yalnızca yukarı yöndeki sonucu gösteriyorsa ürün ekipleri, gecikmeye duyarlı iş akışlarının premium kapasitesinin ne zaman reddedildiğini bilemez.

Yönlendirmeden önce bir yetenek matrisi oluşturun

Hizmet katmanı yönlendiricisinin bir yetenek matrisine ihtiyacı vardır. Matris şu soruyu yanıtlamalıdır: Belirli bir model, bölge, kiracı ve iş akışı için hangi kapasite mekanizmaları kullanılabilir?

Minimum alanlar:

• provider
• model_or_deployment
• regions
• supports_sync
• supports_batch
• supports_premium_tier
• supports_provisioned_capacity
• supports_spillover
• provider_tier_values
• billing_line_items
• known_downgrade_behavior
• tenant_allowlist

Basitleştirilmiş bir örnek:

gateway_tier_map:
  interactive_fast:
    preferred:
      - provider: openai
        request_params:
          service_tier: fast
      - provider: anthropic
        request_params:
          service_tier: priority
    fallback:
      - gateway_tier: interactive_standard
        allowed_when: policy.allows_standard_downgrade

  background_discount:
    preferred:
      - provider: anthropic
        mode: batch
      - provider: gemini
        mode: batch
    fallback:
      - queue: delayed_retry
        allowed_when: true

  reserved_capacity:
    preferred:
      - provider: azure_openai
        deployment_class: provisioned
    fallback:
      - provider: azure_openai
        deployment_class: standard
        allowed_when: policy.allows_spillover

Bu matris dağınık kod değil, yapılandırma olmalıdır. Sağlayıcı adlandırma değişiklikleri, bölgesel kullanılabilirlik ve faturalandırma yöntemi zamanla değişecektir. Bir ağ geçidi politikasını güncellemek, API.

'yi çağıran her uygulamayı yeniden dağıtmaktan daha güvenlidir

Kapasiteyi seçmeden önce iş yüklerini sınıflandırın

En zor kısım sağlayıcı eşlemesi değil. Hangi isteklerin hangi katmanı hak ettiğine karar veriyor.

interactive_fast

için iyi adaylar

• Gecikmenin konuşmayı kesintiye uğrattığı durumlarda sesli asistanlar.
• Yüksek değerli dönüşüm veya elde tutma yolları hakkında müşteriyle yüz yüze sohbet.
• Bir aracının aktif olarak beklediği döngüdeki insan operasyonları.
• Gecikmenin doğrudan azaltmayı etkilediği üretim olayları.

interactive_standard

için iyi adaylar

• Dahili yardımcı pilotlar.
• İnsanın normal yanıt süresini tolere edebileceği bir yerde taslak oluşturmayı destekleyin.
• Yanıt süresinin önemli olduğu ancak kritik olmadığı ürün özellikleri.

background_discount

için iyi adaylar

• Gecelik özeti.
• Geniş belge zenginleştirme.
• Çevrimdışı değerlendirmeler.
• Toplu yerleştirme yenilemeleri.
• Analitik etiketleme ve rapor oluşturma.

reserved_capacity

için iyi adaylar

• Sürekli yüksek hacimli üretim iş yükleri.
• Tahmin edilebilir üretim hızı taahhütleriyle sözleşmeli müşteri iş yükleri.
• Gürültülü komşu değişkenliğini tolere edemeyen ve ayrılmış kapasiteyi haklı çıkaracak kadar yeterli kullanıma sahip olan trafik.

Basit bir politika kuralı şudur: Arayanların yalnızca hızı tercih ettikleri için premium kapasiteyi seçmelerine izin vermeyin. Beyan edilmiş bir iş akışı, kiracı izni ve bütçe kapsamı zorunlu kılın.

Kiracı ve API-anahtar izinlerini zorunlu kılın

Her kiracının ve API anahtarın izin verilen bir katman kümesi olmalıdır. Yeni anahtarlar varsayılan olarak premium katmanlara değil standart ve arka plan katmanlarına ayarlanmalıdır.

Örnek kiracı politikası:

{
  "tenant_id": "tenant_123",
  "allowed_gateway_tiers": [
    "interactive_standard",
    "background_discount"
  ],
  "premium_tier": {
    "enabled": false,
    "monthly_budget_usd": "0.00",
    "approval_required": true
  },
  "reserved_capacity": {
    "enabled": true,
    "deployment_pool": "support-prod-ptu",
    "allow_spillover_to_standard": true,
    "spillover_monthly_budget_usd": "500.00"
  }
}

Örnek anahtar düzeyinde geçersiz kılma:

{
  "api_key_id": "key_voice_prod",
  "allowed_gateway_tiers": ["interactive_fast"],
  "workflow_allowlist": ["voice_control_loop"],
  "premium_daily_budget_usd": "75.00",
  "max_premium_traffic_percent": 15
}

Anahtar düzeyi politikası yanlışlıkla genişletmeyi önler. Bir geliştirici, iş akışına da izin verilmediği sürece, ses trafiğine yönelik bir anahtarı alıp bunu toplu özetleme komut dosyası için kullanamaz.

Sürüm düşürme ve yayılma davranışını açıkça tasarlayın

Sürüm düşürme davranışı yalnızca bir altyapı kararı değil, bir ürün kararıdır. Premium veya sağlanan kapasite kullanılamadığında ağ geçidinin dört yoldan birini seçmesi gerekir:

• Standartlara göre ilerleyin: Kullanılabilirliğin gecikme tutarlılığından daha önemli olduğu durumlarda kullanışlıdır.
• Kuyruk: Arka plan işleri ve toplu iş yükleri için kullanışlıdır.
• Hızlı başarısız olun: Sıkı gerçek zamanlı döngüler gibi, yavaş bir yanıtın yanıt vermemekten daha kötü olacağı durumlarda kullanışlıdır.
• Arayandan yeniden denemesini iste: İstemcinin bir geri alma ve korunmuş bir geçicilik anahtarıyla güvenli bir şekilde yeniden deneyebildiği durumlarda kullanışlıdır.

Örnek politika:

downgrade_policy:
  voice_control_loop:
    requested_tier: interactive_fast
    if_fast_unavailable: fail_fast
    error_code: tier_capacity_unavailable

  customer_support_reply:
    requested_tier: interactive_fast
    if_fast_unavailable: proceed_on_standard
    record_outcome: downgraded

  nightly_document_enrichment:
    requested_tier: background_discount
    if_batch_unavailable: queue
    max_queue_delay_hours: 24

  contracted_api_customer:
    requested_tier: reserved_capacity
    if_reserved_exhausted: spillover_to_standard
    require_spillover_budget: true

Yayılma olayını gizlemeyin. Yayılma kullanılabilirliği artırabilir ancak maliyeti ve SLO yorumunu değiştirir. Faturalar ve analizler ayrılmış kapasite talebini, yayılma olayını, gerçekte kullanılan standart kapasiteyi ve nedenini göstermelidir.

Hizmet katmanı yönlendirmesini faturalandırmaya bağlayın

Kademe seçimi defterin bir parçası değilse ağ geçidi premium harcamayı kontrol edemez. Her istek veya iş için bu alanları saklayın:

• İstenen ağ geçidi katmanı.
• Seçili sağlayıcı katmanı veya kapasite sınıfı.
• Kademe sonucu: seçilmiş, eski sürüme geçirilmiş, yükseltilmiş, sıraya alınmış, yayılma, reddedilmiş.
• Sonucun nedeni.
• Kiracı, API anahtarı, kullanıcı ve iş akışı tanımlayıcıları.
• Model takma adı ve yukarı akış modeli veya dağıtımı.
• Gönderim öncesi tahmini maliyet.
• Sağlayıcı kullanımı bilindikten sonra anlaşılan maliyet.
• Eşzamanlı istekler için gecikme ve yeniden deneme sayısı.
• Eşzamansız işler için toplu gönderim süresi, tamamlanma süresi ve sonuç alma durumu.

Bu alanlarla ağ geçidi, finans ve mühendisliğin soracağı soruları yanıtlayabilir:

• Bu hafta hangi kiracılar premium kapasiteyi kullandı?
• En çok premium harcamaya hangi iş akışları neden oldu?
• Premium istekleri ne sıklıkla standarda düşürüldü?
• interactive_fast, p95 gecikmesini primi haklı çıkaracak kadar iyileştirdi mi?
• Senkronize standart işlemeyle karşılaştırıldığında arka planda toplu işleme ne kadar tasarruf sağladı?
• Temel hazırlığı yapılan kapasite ne kadar standart yayılma oluşturdu?

Önemli öneri: Operasyonel bağlam için istenen katmanı görüntülerken, kullanılan gerçek katmanı faturalandırın. Aksi takdirde kiracılar ya maliyet konusunda şaşıracak ya da hizmet kalitesi konusunda yanıltılacaktır.

Premium'un varsayılan hale gelmemesi için korkuluklar ekleyin

Ekipler daha hızlı bir seviye keşfettiklerinde onu aşırı kullanabilirler. Geniş kullanıma sunmadan önce ağ geçidine sınırlar koyun.

• Kiracı başına prim bütçesi: Sabit aylık ve günlük tavanlar.
• İş akışı onayı: Premium'a yalnızca adlandırılmış iş akışları için izin verilir.
• Trafik paylaşımı sınırı: Örneğin, bir kiracının eşzamanlı isteklerinin %10'undan fazlası onay olmadan interactive_fast'i kullanamaz.
• Standarttan premium'a uyarı: Normalde standart kullanan bir iş akışı yükseltildiğinde uyarı.
• Premium yakma hızı uyarısı: Tahmini harcama, onaylanan sınırı aştığında uyarı.
• Otomatik süre sonu: Geçici acil durum geçersiz kılma işlemlerinin süresi, manuel temizleme olmadan sona ermelidir.
• Toplu uygunluk kontrolleri: Toplu iş ölçütlerini karşıladıkları zaman eşzamanlı premium katmanlardan gelen toplu işleri engelleyin.

Korkuluklar tersine çevrilebilir olmalıdır. Bir olay sırasında, yetkili bir operatörün geçici bir prim geçersiz kılma izni vermesi gerekebilir. Bu geçersiz kılmanın bir nedeni, onaylayanı, bütçesi, son kullanma tarihi ve denetim kaydı bulunmalıdır.

Uygulama sırası

Güvenli bir kullanıma sunma, premium yönlendirmenin her yerde etkinleştirilmesiyle başlamaz. Ölçümle başlayın.

1. Gölge katmanı sınıflandırmasını ekle

Her isteği önerilen bir ağ geçidi katmanına göre sınıflandırın ancak yönlendirmeyi henüz değiştirmeyin. Önerilen katmanı mevcut gecikme, maliyet ve iş akışı meta verilerinin yanına kaydedin. Bu, politikanın uygulanması durumunda ne kadar trafiğin premium, toplu veya ayrılmış kapasiteye taşınacağını gösterir.

2. Yetenek matrisini oluşturun

Sağlayıcı mekanizmalarını, desteklenen modelleri, bölgeleri, sınırları, raporlama alanlarını ve bilinen sürüm düşürme davranışlarını listeleyin. Test edilene kadar bilinmeyen sürüm düşürme davranışlarını risk olarak değerlendirin.

3. Kiracı izinlerini prova modunda zorunlu kılın

Her isteğe izin verilip verilmeyeceğini, eski sürüme geçirilip geçirilmeyeceğini, sıraya alınacağını veya reddedileceğini günlüğe kaydedin. Sonuçları yaptırımdan önce ürün sahipleriyle paylaşın.

4. Bir grup için bir katmanı etkinleştirin

Canlı destek yanıt yolu veya gecelik özetleme işi gibi dar bir iş akışı seçin. Küçük bir kiracı grubu için ilgili ağ geçidi katmanını etkinleştirin. Mevcut olduğunda p50 gecikmesini, p95 gecikmesini, maliyetini, sürüm düşürme oranını, hata oranını ve kullanıcıya yönelik iş ölçümlerini ölçün.

5. Yalnızca veriler desteklediğinde genişletin

Premium katman gecikmeyi artırıyor ancak ürün sonuçlarını iyileştirmiyorsa bunu sınırlı tutun. Toplu işleme, ürün davranışına zarar vermeden maliyeti düşürüyorsa genişletin. Sağlanan kapasite boşta kalırsa taahhüdü tekrar gözden geçirin veya buna daha fazla öngörülebilir trafik yönlendirin.

Açıkça ifade edilecek ödünler

• Düşük gecikme süreli premium katmanlar yanıt verme hızını artırabilir, ancak hız sınırlarını paylaşabilir veya rampa kısıtlamalarını tetikleyebilirler. Bunlar, oran sınırı şekillendirmenin yerine geçmez.
• Tedarik edilen kapasite öngörülebilirliği artırır, ancak kullanım düşük olduğunda para israfına neden olabilir. Ani veya gecikmeye toleranslı trafik için standart veya toplu kapasite daha iyi olabilir.
• Toplu işleme belirteç maliyetini azaltabilir, ancak yanıtlar eşzamansız olduğundan ve çok daha sonra gelebileceğinden ürün davranışını değiştirir.
• Sağlayıcıdan bağımsız katman adları uygulama kodunu basitleştirir, ancak sağlayıcılar farklı adlar, sınırlar, faturalandırma satırları ve sürüm düşürme davranışı kullandığından ağ geçidinin güncel bir yetenek matrisi sağlaması gerekir.
• Otomatik sürüm düşürme, kullanılabilirliği artırır, ancak ağ geçidi kullanılan gerçek katmanı kaydetmediği sürece SLO ve faturalandırma beklentilerini bulanıklaştırabilir.
• Katı kiracı kontrolleri sürpriz harcamaları önler, ancak aşırı katı politikalar, kontrollü bir geçersiz kılma yolu olmadığı sürece acil üretim iş akışlarını engelleyebilir.

Tahmin: Hizmet katmanı birinci sınıf bir yönlendirme boyutu haline gelecek

Tahmin: Model API'leri olgunlaştıkça hizmet katmanı, AI yönlendirme açısından model seçimi, bölge ve bağlam penceresi kadar önemli hale gelecektir. Takımlar sadece “buna hangi model cevap vermeli?” diye sormayacaklar. "Hangi model, hangi kapasite sınıfı altında, hangi kiracı bütçesi için, hangi sürüm düşürme politikasıyla?" diye soracaklar

Öneri: Ağ geçidi defterini ve politika modelini şimdi, uygulama kodunu değiştirmeden yeni sağlayıcı kapasite sınıflarının eklenebileceği şekilde tasarlayın. Yalnızca standart ve toplu ile başlasanız bile en baştan requested_gateway_tier, selected_provider_tier ve tier_outcome gibi alanları kullanın.

Harekete geçirilebilir kontrol listesi

• En fazla beş sağlayıcıdan bağımsız ağ geçidi katmanı tanımlayın.
• Her API anahtarının hangi katmanları ve iş akışlarını kullanabileceğini beyan etmesini zorunlu kılın.
• Premium, standart, temel hazırlık, toplu ve yayılma davranışı için bir sağlayıcı yetenek matrisi oluşturun.
• İstenen katmanı, seçilen katmanı, sürüm düşürme veya yayılma sonucunu, gecikmeyi, kullanımı ve kararlaştırılan maliyeti kaydedin.
• Standart veya arka plan katmanlarına ilişkin varsayılan yeni anahtarlar.
• Premium bütçeler, trafik paylaşımı sınırları ve uyarılar ekleyin.
• İş akışına göre sürüm düşürme davranışını açıkça belirtin.
• Uygulamadan önce gölge metrikleriyle başlayın.
• Premium veya temel hazırlığı yapılmış kapasiteyi önce küçük bir gruba sunun.
• Yalnızca gecikme, güvenilirlik veya iş ölçümleri maliyeti doğruladığında genişletin.

Sonuç

Hizmet katmanı yönlendirmesi, kesişen bir politika kararı olduğundan AI API ağ geçidine aittir. Gecikmeyi, maliyeti, kotaları, kiracı izinlerini, faturaları ve operasyonel beklentileri etkiler. Uygulama ekipleri, yalnızca iş yükünün aciliyetini ifade etmek için sağlayıcıya özel katman adlarını veya dağıtım sınıflarını sabit kodlamamalıdır.

Pratik bir ağ geçidi, interactive_fast, interactive_standard, reserved_capacity ve background_discount gibi tarafsız katmanları ortaya çıkarır. Bu katmanları sağlayıcıya özgü mekanizmalarla eşler, kiracı izinlerini zorunlu kılar, gerçek sonucu kaydeder ve premium kapasiteyi varsayılan yol yerine kasıtlı bir istisna haline getirir.

İlgili okuma

• sağlayıcı 429s'den önce hız sınırı şekillendirme
• eşzamansız toplu iş için dayanıklı ağ geçidi modeli jobs
• teklif, rezervasyon, ödeme ve mutabakat için fatura defteri defteri