Fintech Altyapılarında Sıfır Kesinti Mimarisi

Finansal teknoloji projelerinde kesinti yalnızca teknik bir sorun değildir; işlem kaybı, müşteri güveni, regülasyon riski ve operasyonel itibar anlamına gelir. Fintech altyapısı tasarlarken asıl mesele “sunucu ayakta mı?” sorusundan çok daha geniştir: ödeme akışı, veri tutarlılığı, güvenlik, mevzuat ve felaket senaryoları aynı mimaride birlikte düşünülmelidir.

Kendi projelerimde de gördüğüm en kritik nokta şu: Kesintisiz mimari sonradan eklenen bir özellik değil, ilk tasarım kararlarından itibaren altyapının omurgası olmalıdır.

Fintech Altyapısı

Fintech altyapısı; ödeme, cüzdan, açık bankacılık, kredi, sigorta, muhasebe, kart saklama veya finansal veri işleyen sistemlerin güvenli, ölçeklenebilir ve kesintiye dayanıklı çalışmasını sağlayan teknik katmandır. Bu yapı yalnızca sunucu, veritabanı ve ağdan oluşmaz; güvenlik, gözlemlenebilirlik, mevzuat, iş sürekliliği ve yazılım mimarisi birlikte ele alınır.

Bir fintech sisteminde altyapı tasarımı yapılırken şu sorular baştan cevaplanmalıdır:

• Kritik servisler hangileri?
• Hangi servisler aktif-aktif çalışmalı?
• Hangi veriler senkron, hangileri asenkron çoğaltılmalı?
• Kart verisi, kişisel veri ve işlem logları nerede tutulmalı?
• Felaket anında manuel müdahale gerekecek mi?
• İşlem tutarlılığı mı, erişilebilirlik mi öncelikli?

Katman	Temel Amaç	Fintech Açısından Risk
Ağ	Güvenli erişim ve segmentasyon	Yanlış kural, servis açığı, DDoS
Sunucu/Bulut	Ölçeklenebilir işlem gücü	Kaynak tükenmesi, bölge arızası
Veritabanı	Tutarlı finansal kayıt	Veri kaybı, replikasyon gecikmesi
Güvenlik	Yetkisiz erişimi engelleme	Veri sızıntısı, uyumluluk ihlali
İzleme	Sorunu erken yakalama	Geç fark edilen kesinti

İpucu: Fintech projelerinde “çalışıyor” yeterli bir cevap değildir. Sistem; yoğun işlem saatinde, ağ kaybında, veritabanı gecikmesinde ve servis bağımlılığı bozulduğunda da kontrollü davranmalıdır.

Fintech Nedir

Fintech, finansal hizmetlerin yazılım, veri, bulut, API ve otomasyon teknolojileriyle daha hızlı, erişilebilir ve ölçülebilir şekilde sunulmasıdır. Ödeme kuruluşları, elektronik para şirketleri, dijital cüzdanlar, açık bankacılık servisleri ve finansal SaaS platformları fintech alanına girer.

Fintech tarafında fark yaratan şey yalnızca uygulamanın arayüzü değildir. Arka planda çalışan altyapının güvenilirliği, işlem kayıtlarının doğruluğu, API sürekliliği ve mevzuata uyum düzeyi doğrudan ürün kalitesini belirler.

Fintech Ürünlerinde Altyapının Rolü

Bir kullanıcı ödeme yaptığında saniyeler içinde birçok bileşen çalışır:

1. Kullanıcı kimliği doğrulanır.
2. İşlem limiti ve risk kuralları kontrol edilir.
3. Ödeme sağlayıcı veya banka API’sine istek atılır.
4. İşlem sonucu kaydedilir.
5. Bildirim, mutabakat ve log süreçleri tetiklenir.

Bu zincirin herhangi bir halkasında gecikme veya hata varsa kullanıcı bunu “ödeme başarısız” olarak görür. Bu yüzden fintech altyapısı, yazılım geliştirme sürecinin dışında değil tam merkezinde olmalıdır.

Fintech Altyapısı Kesintisiz Mimari

Fintech altyapısı kesintisiz mimari, tek bir bileşenin arızalanmasının tüm sistemi durdurmaması için tasarlanan yüksek erişilebilirlik yaklaşımıdır. Burada amaç yalnızca uptime değerini yükseltmek değil; işlem bütünlüğünü koruyarak servislerin planlı veya plansız kesintilerde çalışmaya devam etmesini sağlamaktır.

Kesintisiz mimaride en sık kullanılan yaklaşımlar şunlardır:

• Aktif-aktif veri merkezi veya bulut bölgesi
• Load balancer ve health check mekanizmaları
• Otomatik failover
• Çoklu veritabanı replikasyonu
• Mesaj kuyruğu ile gevşek bağlı servisler
• Blue-green veya canary deployment
• Merkezi loglama ve alarm üretimi
• WAF, Firewall ve DDoS koruması

Mimari Model	Kullanım Durumu	Avantaj	Dikkat Edilmesi Gereken
Aktif-Pasif	Orta kritik sistemler	Daha düşük maliyet	Geçiş süresi iyi test edilmeli
Aktif-Aktif	Yüksek işlem hacmi	Kesintiye daha dayanıklı	Veri tutarlılığı karmaşıklaşır
Multi-Region	Coğrafi yedeklilik	Bölgesel arızaya dayanıklı	Ağ gecikmesi ve maliyet artar
Hibrit	Regülasyon + esneklik	Kritik veri kontrol altında kalır	Operasyon karmaşası oluşabilir

Tek Nokta Arızası Bırakmamak

Fintech sistemlerinde en sık yapılan hata, uygulama sunucularını yedekleyip veritabanını tekil bırakmaktır. Oysa gerçek kesintiler çoğu zaman veritabanı, ağ geçidi, DNS, sertifika, Firewall kuralı veya üçüncü taraf API bağımlılığı üzerinden gelir.

Kesintisiz mimari için şu bileşenler tekil bırakılmamalıdır:

• Load balancer
• Firewall
• Veritabanı
• DNS sağlayıcısı
• VPN veya özel bağlantı
• Loglama sistemi
• Kimlik doğrulama servisi
• Mesaj kuyruğu

Fintech Altyapılarında Neler Önemlidir

Fintech altyapılarında güvenlik, erişilebilirlik, veri tutarlılığı, mevzuata uyum, izlenebilirlik ve ölçeklenebilirlik birlikte değerlendirilmelidir. Bir sistem çok hızlı olabilir ancak yeterince izlenemiyorsa risklidir; çok güvenli olabilir ancak felaket anında ayağa kalkamıyorsa finansal operasyon için yetersizdir.

Önceliklendirme yaparken teknik ekiplerin şu başlıkları ayrı ayrı ölçmesi gerekir:

Öncelik	Neden Önemli?	Ölçüm Yöntemi
Erişilebilirlik	Kullanıcı işlemlerinin devamı	Uptime, hata oranı
Veri bütünlüğü	Finansal kayıt doğruluğu	Mutabakat, transaction log
Güvenlik	Veri ve işlem koruması	Penetrasyon testi, SIEM alarmı
Performans	İşlem deneyimi	P95/P99 gecikme
Uyumluluk	Yasal ve sektörel gereklilik	Denetim raporları

Gözlemlenebilirlik Olmadan Kesintisizlik Yönetilemez

Monitoring yalnızca CPU ve RAM izlemek değildir. Fintech sistemlerinde işlem bazlı gözlemlenebilirlik gerekir.

Takip edilmesi gereken pratik metrikler:

• Başarılı/başarısız işlem oranı
• API yanıt süresi
• Üçüncü taraf servis gecikmeleri
• Veritabanı kilitlenmeleri
• Queue derinliği
• Mutabakat farkları
• Şüpheli trafik paterni
• Sertifika bitiş tarihleri

Uyarı: Bir sistemin alarm üretmemesi, sorunsuz çalıştığı anlamına gelmez. Yanlış eşikler, eksik loglar veya sessiz hatalar fintech operasyonlarında ciddi risk oluşturur.

Fintech Altyapısında Mevzuatlara ve PCI DSS Uyumluluk

Fintech altyapısında mevzuatlara ve PCI DSS uyumluluk, kart verisi, kişisel veri ve finansal işlem kayıtlarının belirlenmiş güvenlik kontrolleriyle korunmasını ifade eder. Uyumluluk yalnızca dokümantasyon işi değildir; ağ segmentasyonu, erişim kontrolü, şifreleme, loglama ve düzenli test süreçleriyle teknik olarak kanıtlanmalıdır.

PCI DSS özellikle kart sahibi verisinin işlendiği, saklandığı veya iletildiği sistemlerde önemlidir. Eğer kart verisi doğrudan tutulmuyorsa bile tokenizasyon, ödeme geçidi entegrasyonu ve log maskeleme doğru tasarlanmalıdır.

PCI DSS İçin Temel Teknik Kontroller

Kontrol Alanı	Pratik Uygulama
Ağ güvenliği	Firewall segmentasyonu, kapalı port politikası
Veri koruma	Şifreleme, tokenizasyon, maskeleme
Erişim yönetimi	MFA, least privilege, rol bazlı erişim
Loglama	Değiştirilemez log, merkezi SIEM
Test	Zafiyet taraması, penetrasyon testi
Operasyon	Olay müdahale planı, değişiklik yönetimi

Fintech mimarilerinde KVKK, yerel finansal düzenlemeler, saklama süreleri, erişim kayıtları ve denetim izleri de tasarımın parçası olmalıdır. Yazılım geliştirme ekipleri ile altyapı ekipleri bu noktada birlikte çalışmalıdır; aksi halde uygulama seviyesinde alınan kararlar altyapı uyumluluğunu zayıflatabilir.

Fintech Bulut Altyapısı

Fintech bulut altyapısı, finansal sistemlerin ölçeklenebilir, izlenebilir ve yedekli çalışması için bulut servisleriyle tasarlanan altyapı modelidir. Doğru kurgulandığında hızlı kaynak artırımı, otomatik yedeklilik, güvenlik servisleri ve felaket kurtarma senaryoları açısından ciddi avantaj sağlar.

Bulut seçimi yapılırken yalnızca fiyat veya popülerlik üzerinden karar verilmemelidir. Veri lokasyonu, uyumluluk, bağlantı kalitesi, yönetilen servis seçenekleri ve çıkış stratejisi birlikte değerlendirilmelidir.

Bulut Altyapısında Kritik Kararlar

• Veriler hangi lokasyonda tutulacak?
• Kritik servisler farklı availability zone üzerinde mi çalışacak?
• Snapshot ve backup politikası nasıl olacak?
• Veritabanı yönetilen servis mi, self-managed mı olacak?
• Trafik artışında otomatik ölçekleme devreye girecek mi?
• Buluttan çıkış veya ikinci sağlayıcı senaryosu var mı?

Kriter	Self-Managed	Yönetilen Bulut Servisi
Kontrol	Daha yüksek	Daha sınırlı
Operasyon yükü	Fazla	Daha düşük
Güncelleme yönetimi	Ekibe bağlı	Sağlayıcı destekli
Uyumluluk dokümantasyonu	Manuel hazırlanır	Daha hazır gelir
Maliyet öngörülebilirliği	İyi plan ister	Kullanıma göre değişir

Finans Bulutu

Finans bulutu, finans sektörünün güvenlik, regülasyon, veri yerleşimi ve operasyonel süreklilik ihtiyaçlarına göre tasarlanmış bulut yaklaşımıdır. Standart bulut servislerinden farklı olarak erişim kontrolü, denetim izi, veri izolasyonu ve uyumluluk beklentileri daha sıkı ele alınır.

Finans bulutu tercih edilirken şu noktalara bakılmalıdır:

• Veri merkezinin fiziksel güvenliği
• Sertifikasyon ve denetim geçmişi
• Şifreleme anahtarı yönetimi
• Network izolasyonu
• Log saklama ve denetim izi
• İş sürekliliği taahhütleri
• Regülasyonlara uygun sözleşme yapısı

Finansal sistemlerde her iş yükü aynı hassasiyette değildir. Örneğin statik içerik servisleri ile kart işlem altyapısı aynı güvenlik zonunda bulunmamalıdır. İyi bir finans bulutu mimarisi, sistemleri risk seviyesine göre ayırır.

Finans Topluluk Bulutu

Finans topluluk bulutu, benzer regülasyonlara tabi finans kuruluşlarının ortak güvenlik ve uyumluluk beklentilerine göre yapılandırılmış bulut modelidir. Bu yaklaşım, standart genel buluta göre daha kontrollü; tamamen özel buluta göre ise daha paylaşılabilir ve ölçeklenebilir bir yapı sunabilir.

Bu model özellikle şu durumlarda değerlendirilebilir:

• Birden fazla finansal kuruluş benzer uyumluluk gereksinimlerine sahipse
• Ortak güvenlik politikaları uygulanabiliyorsa
• Veri izolasyonu teknik ve hukuki olarak net tanımlanmışsa
• Denetim süreçleri ortak standartlara göre yürütülebiliyorsa

Bulut Modeli	Uygun Senaryo	Güçlü Yanı	Risk
Genel Bulut	Düşük/orta hassas iş yükleri	Esneklik	Regülasyon analizi gerekir
Özel Bulut	Kritik finansal sistemler	Kontrol	Maliyet ve operasyon yükü
Topluluk Bulutu	Benzer regülasyondaki kurumlar	Ortak standart	Yönetim modeli net olmalı
Hibrit Bulut	Parçalı iş yükleri	Esneklik + kontrol	Entegrasyon karmaşası

Felaket Kurtarma Merkezi

Felaket kurtarma merkezi, ana sistemlerin çalışamaz hale gelmesi durumunda kritik servislerin belirlenen süre ve veri kaybı hedefleriyle yeniden devreye alınmasını sağlayan yedek operasyon ortamıdır. Fintech projelerinde bu merkez, yalnızca yedek sunucu barındırmak için değil, işlem sürekliliğini korumak için tasarlanmalıdır.

Disaster recovery tarafında yapılan en büyük hata, dokümanda var olan planın gerçek hayatta test edilmemesidir. Felaket senaryosu; ağ, DNS, uygulama, veritabanı, güvenlik ve operasyon ekibiyle birlikte uçtan uca denenmelidir.

Felaket Senaryosu Örnekleri

• Ana veri merkezinde enerji kesintisi
• Bulut bölgesi erişim problemi
• Veritabanı bozulması
• Yanlış deploy nedeniyle servis çökmesi
• DDoS saldırısı
• Firewall veya routing hatası
• Üçüncü taraf ödeme servisinin yanıt vermemesi
• Fidye yazılımı riski

Felaket Kurtarma Merkezi Nedir

Felaket kurtarma merkezi nedir sorusunun pratik cevabı şudur: Ana ortam devre dışı kaldığında işin devam edebilmesi için hazır tutulan ikinci operasyon noktasıdır. Bu merkez fiziksel veri merkezi, farklı bulut bölgesi, hibrit yapı veya özel olarak ayrılmış yedek platform olabilir.

Bir felaket kurtarma merkezinin işe yaraması için üç unsur birlikte bulunmalıdır:

1. Güncel veri kopyası
2. Çalıştırılabilir uygulama ortamı
3. Test edilmiş geçiş prosedürü

Sadece backup almak felaket kurtarma değildir. Backup, verinin geri alınmasını sağlar; felaket kurtarma ise servisin tekrar çalışır hale gelmesini hedefler.

Felaket Kurtarma Merkezi Standartları

Felaket kurtarma merkezi standartları; erişilebilirlik, fiziksel güvenlik, veri yedekliliği, ağ sürekliliği, izleme, erişim yönetimi ve test prosedürlerini kapsar. Standart yaklaşım, sistemlerin hangi felaket türünde nasıl davranacağını önceden tanımlamaktır.

Dikkat edilmesi gereken başlıklar:

• Coğrafi ayrışma
• Bağımsız enerji ve ağ altyapısı
• Güvenli bağlantı tünelleri
• Şifreli veri replikasyonu
• Düzenli failover testi
• Erişim yetki matrisi
• Olay müdahale planı
• Denetim kayıtları

Standart Alan	Beklenen Yaklaşım
Fiziksel güvenlik	Kontrollü giriş, kamera, kayıt
Ağ	Yedekli bağlantı, segmentasyon
Veri	Şifreli replikasyon, backup doğrulama
Operasyon	Runbook, görev dağılımı
Test	Periyodik geçiş tatbikatı
Raporlama	Test sonucu ve aksiyon listesi

Felaket Kurtarma RPO Nedir

Felaket kurtarma RPO nedir sorusunun cevabı, kabul edilebilir maksimum veri kaybı süresidir. Örneğin RPO 5 dakika ise sistem felaket anında en fazla son 5 dakikalık veriyi kaybetmeyi hedefler; bu hedef replikasyon, backup ve işlem kayıt tasarımını doğrudan etkiler.

Fintech sistemlerinde RPO çoğu zaman çok düşük tutulmak istenir. Ancak RPO’yu sıfıra yaklaştırmak maliyeti ve mimari karmaşıklığı artırır. Bu nedenle her servis için ayrı RPO belirlemek daha gerçekçidir.

Servis Türü	Önerilen RPO Yaklaşımı
Finansal işlem kayıtları	Saniyeler / sıfıra yakın
Kullanıcı profil verisi	Dakikalar
Raporlama verisi	Saatlik olabilir
Log arşivi	Kullanım amacına göre
Statik içerik	Daha esnek

Felaket Kurtarma RTO Nedir

Felaket kurtarma RTO nedir sorusunun cevabı, bir sistemin felaket sonrası ne kadar sürede tekrar çalışır hale getirilmesi gerektiğidir. RTO 15 dakika olarak tanımlandıysa altyapı, ekip ve geçiş prosedürü bu süreyi karşılayacak şekilde hazırlanmalıdır.

RTO yalnızca teknik hız değildir. DNS geçişi, ekip koordinasyonu, güvenlik onayı, uygulama bağımlılıkları ve müşteri iletişimi de bu sürenin parçasıdır.

RPO ve RTO Arasındaki Fark

Kavram	Neyi Ölçer?	Örnek
RPO	Ne kadar veri kaybı kabul edilir?	En fazla 5 dakika veri kaybı
RTO	Sistem ne kadar sürede açılmalı?	15 dakika içinde servis dönüşü
Backup	Veri geri alma yöntemi	Günlük/saatlik yedek
Replikasyon	Veriyi sürekli kopyalama	Anlık veya gecikmeli kopya

İpucu: RTO ve RPO değerlerini tüm sistem için tek sayı olarak belirlemek yanıltıcıdır. Ödeme servisi, raporlama servisi ve yönetim paneli aynı öncelikte değildir.

Sıkça Sorulan Sorular

Fintech altyapısı neden klasik web altyapısından farklıdır?

Fintech altyapısı klasik web altyapısından farklıdır çünkü finansal işlem, kişisel veri, regülasyon, mutabakat ve yüksek erişilebilirlik gereksinimlerini birlikte taşır. Bir e-ticaret sitesinde kısa süreli kesinti rahatsızlık yaratabilir; fintech tarafında ise ödeme akışı bozulabilir, işlem kayıtları tutarsızlaşabilir veya denetim riski oluşabilir. Bu nedenle fintech mimarisinde güvenlik, loglama, veri bütünlüğü, felaket kurtarma ve uyumluluk baştan tasarlanmalıdır.

Sıfır kesinti gerçekten mümkün mü?

Teknik olarak mutlak sıfır kesinti iddiası gerçekçi değildir; ancak doğru mimariyle kullanıcıya yansıyan kesinti süresi çok düşük seviyelere indirilebilir. Aktif-aktif yapı, otomatik failover, dağıtık veritabanı, kesintisiz deployment ve iyi test edilmiş felaket senaryoları bu hedefe yaklaşmayı sağlar. Burada önemli olan sistemin arıza anında kontrollü davranması ve kritik işlemleri kayıpsız sürdürebilmesidir.

Fintech projelerinde aktif-aktif mimari ne zaman gerekir?

Aktif-aktif mimari, işlem hacmi yüksek, kesinti toleransı düşük ve coğrafi yedeklilik ihtiyacı olan fintech projelerinde tercih edilir. Ödeme, cüzdan, kart işlem veya kritik API servislerinde tek bölgeye bağımlı kalmak risk yaratabilir. Ancak aktif-aktif yapı veri tutarlılığı, replikasyon gecikmesi ve maliyet açısından dikkatli tasarlanmalıdır. Her servis için aktif-aktif şart değildir; kritik iş yükleri önceliklendirilmelidir.

PCI DSS uyumluluğu her fintech için zorunlu mudur?

PCI DSS, kart sahibi verisinin işlendiği, saklandığı veya iletildiği sistemlerde gündeme gelir. Kart verisi doğrudan tutulmuyorsa bile ödeme akışı içinde kart bilgisi temas ediyorsa kapsam analizi yapılmalıdır. Tokenizasyon, ödeme kuruluşu yönlendirmesi ve log maskeleme kapsamı azaltabilir. Yine de fintech projelerinde PCI DSS dışında KVKK, finansal düzenlemeler ve sözleşmesel güvenlik yükümlülükleri ayrıca değerlendirilmelidir.

Felaket kurtarma planı ne sıklıkla test edilmelidir?

Felaket kurtarma planı en az yılda birkaç kez ve kritik altyapı değişikliklerinden sonra test edilmelidir. Sadece doküman kontrolü yeterli değildir; gerçek failover, veri geri dönüşü, DNS geçişi, uygulama ayağa kaldırma ve ekip koordinasyonu denenmelidir. Test sonunda RTO ve RPO hedeflerinin karşılanıp karşılanmadığı ölçülmeli, eksikler aksiyon listesine dönüştürülmelidir.

Backup almak felaket kurtarma için yeterli mi?

Backup almak önemlidir ancak tek başına felaket kurtarma değildir. Backup veriyi geri getirmeye yarar; felaket kurtarma ise servisin belirlenen sürede çalışır hale gelmesini hedefler. Eğer yedekten dönüş saatler sürüyor, uygulama ortamı hazır değil veya DNS geçişi planlanmamışsa iş sürekliliği sağlanamaz. Fintech sistemlerinde backup, replikasyon ve test edilmiş geçiş prosedürü birlikte düşünülmelidir.

RPO değeri fintech sistemlerinde nasıl belirlenir?

RPO değeri, ilgili serviste ne kadar veri kaybının kabul edilebilir olduğuna göre belirlenir. Finansal işlem kayıtlarında RPO genellikle saniyeler seviyesinde veya sıfıra yakın hedeflenir. Raporlama, analiz veya statik içerik gibi daha az kritik sistemlerde daha esnek değerler seçilebilir. Her servise aynı RPO’yu vermek maliyetli ve gereksiz olabilir; iş etkisi analizi yapılmalıdır.

RTO düşük tutulursa maliyet artar mı?

Evet, RTO değeri düştükçe genellikle maliyet artar. Çünkü sistemin çok kısa sürede ayağa kalkması için hazır bekleyen kaynaklar, otomatik failover, güncel replikasyon, yedek ağ bağlantıları ve düzenli test süreçleri gerekir. Bu nedenle her servis için iş önceliğine göre RTO belirlenmelidir. Ödeme servisi için dakikalar hedeflenirken, raporlama servisi için daha uzun süre kabul edilebilir.

Finans bulutu ile genel bulut arasındaki temel fark nedir?

Finans bulutu, finans sektörünün güvenlik, denetim, veri yerleşimi ve uyumluluk beklentilerine göre daha kontrollü yapılandırılmış bulut yaklaşımıdır. Genel bulut esneklik ve ölçeklenebilirlik sağlar; finans bulutu ise buna ek olarak daha sıkı erişim kontrolü, denetim izi, izolasyon ve regülasyon uyumu odağı taşır. Hangi modelin uygun olduğu iş yükünün hassasiyetine göre belirlenmelidir.

Fintech altyapısında Firewall neden kritik rol oynar?

Firewall, fintech altyapısında ağ segmentasyonu, erişim kontrolü ve saldırı yüzeyinin daraltılması için kritik bir bileşendir. Ancak yalnızca cihaz konumlandırmak yeterli değildir; kurallar düzenli gözden geçirilmeli, gereksiz portlar kapatılmalı, loglar SIEM sistemine aktarılmalı ve yüksek erişilebilirlik yapılandırması yapılmalıdır. Yanlış Firewall kuralı hem güvenlik açığına hem de beklenmeyen kesintiye neden olabilir.

İlgili İçerikler

• Fintech Projelerinde Firewall Mimarisi Nasıl Tasarlanmalı?
• Bulut Altyapısında Yüksek Erişilebilirlik Yaklaşımları
• PCI DSS Uyumlu Sistem Tasarımında Teknik Kontroller
• Disaster Recovery Planı Hazırlarken Yapılan Hatalar
• Mikroservis Mimarilerinde Finansal İşlem Tutarlılığı

Fintech altyapısı tasarlarken kesintisizlik, güvenlik ve mevzuat aynı masada ele alınmalıdır. Kişisel olarak Firewall, bulut altyapısı ve yazılım geliştirme tarafında aktif projeler yürütürken en net gördüğüm şey şu: Sağlam mimari, yalnızca iyi teknoloji seçimiyle değil; doğru önceliklendirme, test disiplini ve operasyon tecrübesiyle ortaya çıkar.

Bu alanda daha fazla teknik not, saha deneyimi ve mimari yaklaşım paylaşımı için dogus.net.tr üzerindeki içerikleri takip edebilirsiniz.