Çok sağlayıcılı envanter tek modelde birleşti, aynı hacim %20 daha düşük cloud maliyetine indi.

Otobüs ve tren envanterini global ölçekte sunan bir platformda; birbirinden farklı sağlayıcı API’lerini ortak bir iç modele taşıdık, arıza kaynaklarını ayrıştırdık ve yüksek trafikte sürekliliği koruyan bir koruma katmanı kurduk.

%20daha düşük cloud maliyeti 10K+ RPSölçek deneyimi 7/24izleme ve trafik koruması
Problem

Her sağlayıcı kendi modelini dayatıyordu

Envanter birden fazla sağlayıcıdan geliyordu ve her birinin veri modeli, iş kuralları ve hata davranışı farklıydı. Bu fark ürüne sızdığında iki sonuç doğuyordu: yeni sağlayıcı entegrasyonu her seferinde sıfırdan yazılıyor, bir sağlayıcıdaki aksaklık ise kullanıcıya platformun tamamı bozulmuş gibi yansıyordu.

Başlangıçtaki durum

  • Sağlayıcıya özel davranışların ürün koduna sızması
  • İstasyon ve şehir eşleşmelerinin manuel düzeltilmesi
  • Aksaklıkta kök nedenin tartışmayla bulunmaya çalışılması
  • Yoğun dönemlerde ve saldırgan trafikte kararsızlık
Mimari akış

Sağlayıcıdan kullanıcıya.

Envanterin sağlayıcıdan çıkıp kullanıcıya ulaşana kadar geçtiği katmanlar ve her katmanın sorumluluğu.

Envanter akış mimarisi Sağlayıcı A Sağlayıcı B Sağlayıcı C n adet Entegrasyon LLM NORMALIZASYON SIMILARITY + VECTOR DB GIS / PLACES ESLESTIRME SAGLAYICI SOZLESMESI Ortak iç model ARAMA · DETAY · SATIS RETRY · TIMEOUT CIRCUIT BREAKER GRACEFUL FALLBACK Kenar koruma WAF · RATE LIMITING CHALLENGE AKISLARI ADAPTIVE ROUTING THROTTLING Kullanıcı Observability METRICS · LOGS · DISTRIBUTED TRACING · ALERTING — SAGLAYICI / IC SISTEM / ODEME HATALARININ AYRISTIRILMASI
Her sağlayıcı kendi sözleşmesiyle entegrasyon katmanına bağlanır; ortak iç modele çevrildikten sonra ürün akışları sağlayıcıdan bağımsız çalışır. Kenar koruma katmanı aşırı ve kötücül trafiği filtreler, observability katmanı ise hatanın hangi katmanda doğduğunu ayrıştırır.
Yaklaşım

Dört katmanda
ele aldık.

Entegrasyonu tek seferlik bir iş değil, üzerine sağlayıcı eklenebilen kalıcı bir katman olarak kurduk.

01 Entegrasyon

Ortak iç model

Her sağlayıcının iş mantığı analiz edildi ve tek bir platform sözleşmesine hizalandı.

Neler yaptık
  • Provider API’lerinin uçtan uca analizi ve davranış farklarının soyutlanması
  • İstasyon / şehir eşleştirmesi: yakınlık, isim benzerliği, GIS ve Google Places
  • Yeni sağlayıcı eklemeyi hızlandıran tekrarlanabilir entegrasyon şablonu
02 AI

Veri normalizasyonu

Yapılandırılmamış sağlayıcı verisini manuel olarak değil, model destekli akışlarla standarda taşıdık.

Neler yaptık
  • OpenAI tabanlı normalizasyon ile serbest metin alanların standart formata çevrilmesi
  • LLaMA ve similarity scoring ile otomatik model hizalama
  • Vector database üzerinden benzerlik aramasıyla eşleştirme doğruluğunun artırılması
03 Observability

Kök neden ayrıştırma

Arama, detay ve satın alma akışlarındaki bozulmayı gerçek zamanlı görünür hale getirdik.

Neler yaptık
  • Metrics, logs ve distributed tracing ile uçtan uca izlenebilirlik
  • Otomatik alerting eşikleriyle bozulmanın erken yakalanması
  • Sağlayıcı, iç sistem ve ödeme kaynaklı hataların birbirinden ayrılması
  • Bölge ve sağlayıcı bazlı dönüşüm takibi, strateji ekibiyle akış düzenlemeleri
04 Dayanıklılık

Trafik koruması ve süreklilik

Dış dünyadaki kararsızlığın çekirdek sistemlere yayılmasını engelledik.

Neler yaptık
  • Retry, timeout ve circuit breaker desenlerinin uçtan uca uygulanması
  • Graceful fallback ve degraded-mode ile kısmi arızada süreklilik
  • Cloudflare WAF, rate limiting ve challenge akışlarıyla kötücül trafiğin filtrelenmesi
  • Bölge ve sağlayıcı yüküne göre adaptive routing / throttling
Sonuçlar

Ne değişti?

Çıktıları yalnızca teknik metriklerle değil, ürün ve operasyon tarafındaki etkileriyle birlikte takip ettik.

Platform davranışı

Sağlayıcıdan bağımsız, öngörülebilir bir ürün deneyimi.
Model
Çok sağlayıcılı envanter tek iç modelde birleşti; ürün kodu sağlayıcı detayından arındı.
Süreklilik
Tek bir bağımlılığın yavaşlaması tüm akışı durdurmuyor; sistem kontrollü şekilde degrade oluyor.
Görünürlük
Aksaklığın kaynağı (sağlayıcı / iç sistem / ödeme) dakikalar içinde ayrıştırılabiliyor.
Maliyet
Kullanılmayan servisler kaldırıldı, kaynaklar yeniden boyutlandırıldı; aynı iş hacmi yaklaşık %20 daha düşük maliyetle karşılanıyor.
Ekip
GitHub Copilot benimsenmesi, prompt ve kullanım standartlarıyla geliştirme hızında artış.

Rolümüz

Teknik liderlik ve uçtan uca sorumluluk.
Rol
Tech lead · mimari, standartlar ve mentorluk
Kapsam
Mimari tasarım, entegrasyon, observability, trafik koruması, maliyet
Çalışma
Ürün, strateji ve ödeme ekipleriyle ortak yürütme

Teknoloji

Üretim ortamında kullanılan başlıca bileşenler.
AWS.NETOpenAI API LLaMAVector DBOpenTelemetry JaegerCloudflareRedis ElasticsearchRabbitMQ
İlgili platform çözümü

Bu çalışma, seyahat dağıtım platformu çözümümüzün kaynağıdır.

Benzer bir platform ihtiyacınız varsa buradan başlayabiliriz.

Travel Distribution Platform → Tüm platform çözümleri →
Bu çalışmada kullanılan hizmetler

İlgili başlıklar

02 · Hizmet Systems Integration & API Engineering Contract-first API tasarımı, anti-corruption layer ve veri normalizasyonu. 05 · Hizmet Site Reliability Engineering Observability, resilience desenleri ve kök neden ayrıştırması. 06 · Hizmet Application & API Security WAF, rate limiting, challenge akışları ve adaptive throttling.
Birlikte çalışalım

Sizin de birden fazla sağlayıcıyla çalışan bir platformunuz mu var?

Mevcut entegrasyon yapınızı anlatın; nereden başlanması gerektiğine birlikte karar verelim.

Projeyi başlatalım → Tüm çalışmalarımızı görün