Mobil Uygulama Backend Altyapısı Nasıl Kurulur?

Mobil uygulama backend altyapısı nasıl kurulur sorusu, güncel yazılım mühendisliği disiplininde sadece bir sunucu kiralamaktan çok daha öte; veri tutarlılığı, ölçeklenebilir ağ katmanları, yasal uyumluluk standartları ve kesintisiz çalışma taahhüdü (SLA) üzerine kurulu bir ekosistem tasarımı anlamına gelir. Teknik karar vericiler, CTO'lar ve ürün yöneticileri için backend kurulum süreci, uygulamanın yaşam döngüsü boyunca ortaya çıkacak bakım maliyetlerini, performans darboğazlarını ve siber güvenlik risklerini belirleyen en kritik aşamadır. Bu rehberde, global ölçekte milyarlarca isteği işleyebilecek kapasitede, esnek ve güvenli bir mobil uygulama backend altyapısının sıfırdan kurulumunu, mimari seçimlerini ve kurumsal standartlarını tüm teknik detaylarıyla inceleyeceğiz.

Mobil Backend Altyapısında Stratejik Yaklaşım ve Planlama

İhtiyaç Analizi: Monolitik, Mikroservis veya Serverless Mimarisi?

Mobil uygulama projelerinde backend altyapısı kurulurken verilecek ilk ve en radikal karar, kod tabanının ve çalışma mantığının hangi mimari şablon üzerine inşa edileceğidir. Yazılım dünyasında uzun yıllar standart olarak kabul edilen monolitik (monolithic) yapılar, tüm uygulama bileşenlerinin (kullanıcı yönetimi, ödeme sistemleri, bildirimler, veritabanı erişimi) tek bir büyük kod tabanında toplandığı sistemlerdir. Monolitik mimari, özellikle erken aşama girişimler ve MVP (Minimum Viable Product) projeleri için geliştirme hızını maksimuma çıkarma avantajı sunar. Dağıtık sistemlerin getirdiği karmaşık ağ yönetimi ve veri tutarlılığı (eventual consistency) gibi problemlerle uğraşılmadığı için küçük ekipler tarafından kolayca yönetilir, test edilir ve tek bir sunucuya (örneğin tek bir sanal sunucu - VPS) kolaylıkla canlıya alınabilir.

Ancak monolitik yapının sınırları, mobil uygulamanın kullanıcı sayısı ve özellik seti genişledikçe hızla belirginleşir. Kod tabanının büyümesi, derleme (build) sürelerini uzatır; tek bir fonksiyondaki hata veya bellek sızıntısı (memory leak) tüm sistemin çökmesine neden olur. Bu darboğazları aşmak için geliştirilen mikroservis (microservices) mimarisi ise uygulamayı bağımsız olarak ölçeklendirilebilen, kendi veritabanına sahip ve birbirleriyle hafif protokollerle (HTTP/REST, gRPC veya RabbitMQ, Apache Kafka gibi mesaj kuyrukları) haberleşen küçük servis birimlerine böler. Mikroservisler, farklı ekiplerin birbirine bağımlı olmadan çalışabilmesini sağlar; örneğin, uygulamanın sohbet modülü yüksek trafik alıyorsa sadece sohbet servisi yatayda ölçeklendirilirken, daha az trafik alan ödeme modülü aynı kaynak seviyesinde kalabilir. Bununla birlikte, dağıtık sistemlerin yönetimi yüksek düzeyde DevOps uzmanlığı, API Gateway (Kong, AWS API Gateway vb.) entegrasyonu ve karmaşık log izleme (distributed tracing) altyapısı gerektirir.

Üçüncü bir alternatif olan sunucusuz (serverless) mimari (FaaS - Function as a Service) ise AWS Lambda, Google Cloud Functions veya Azure Functions gibi yapılar üzerinden kurgulanır. Bu modelde fiziksel sunucu yönetimi tamamen bulut sağlayıcıya devredilir; kodlar sadece belirli bir tetikleyici olay (event) gerçekleştiğinde çalışır ve saniye veya milisaniye bazında ücretlendirilir. Serverless mimarisi, trafiği anlık ve düzensiz dalgalanmalar gösteren mobil uygulamalar için mükemmel bir maliyet optimizasyonu ve sıfır yönetim kolaylığı sağlar. Ancak "cold start" (soğuk çalışma) adı verilen, uzun süre tetiklenmeyen fonksiyonların ilk çağrılışında yaşanan birkaç saniyelik gecikme, mobil uygulamalarda kullanıcı deneyimini olumsuz etkileyebilir. Ayrıca, uzun süreli ve yoğun veri işleme gerektiren iş yüklerinde serverless kullanımı, geleneksel sunucu barındırma modellerine göre çok daha yüksek faturalarla karşılaşılmasına sebep olabilir.

BaaS (Hizmet Olarak Backend) ve Özel (Custom) Backend Karşılaştırması

Teknik karar vericilerin önündeki bir diğer stratejik yol ayrımı, Firebase, Supabase veya Appwrite gibi hazır BaaS (Backend as a Service) platformlarını kullanmak ile sıfırdan özel (custom) bir backend yazmak arasındadır. BaaS platformları; kullanıcı kimlik doğrulama (Authentication), anlık veritabanı (Realtime Database), dosya depolama (Storage) ve push notification gibi mobil uygulamaların %80'inde ortak olan özellikleri hazır SDK'lar halinde sunar. Bu sayede bir backend ekibine ihtiyaç duymadan, sadece mobil geliştiriciler (iOS/Android, Flutter, React Native) doğrudan bu platformları kullanarak uygulamayı birkaç hafta içinde canlıya alabilir. Zaman kısıtlaması olan ve pazar doğrulama (market validation) hedefleyen projeler için BaaS kullanımı, pazara giriş süresini (time-to-market) ciddi oranda kısaltır.

Ancak, BaaS platformlarının kullanımı derin teknik kısıtlamaları ve ticari riskleri de beraberinde getirir. En büyük risklerden biri "vendor lock-in" (sağlayıcıya bağımlılık) durumudur. Örneğin, uygulamanız Firebase üzerinde büyüdüğünde ve özelleştirilmiş, karmaşık SQL sorguları yazmanız, makine öğrenmesi modelleri çalıştırmanız veya yerel yasal mevzuatlara (KVKK) uymanız gerektiğinde Firebase'den çıkıp kendi sunucularınıza taşınmak devasa bir yeniden yazım maliyeti doğurur. Ayrıca, BaaS platformlarının okuma/yazma odaklı fiyatlandırma modelleri, optimize edilmemiş sorgular içeren yüksek trafikli uygulamalarda beklenmedik astronomik faturalara yol açabilir. Özel (custom) backend altyapısı kurmak ise başlangıçta Node.js (NestJS, Express), Python (FastAPI, Django) veya Go (Fiber, Gin) gibi dillerle geliştirme yapmayı ve sunucu yönetimini üstlenmeyi gerektirse de, uzun vadede sınırsız esneklik, tam veritabanı kontrolü ve daha öngörülebilir, ölçeklenebilir maliyet yönetimi sunar.

Sunucu ve Barındırma Altyapısının Yapılandırılması

Kurumsal İhtiyaçlara Göre Bulut Sağlayıcı Seçimi (AWS, Azure, GCP)

Mobil uygulama backend sunucularının barındırılacağı bulut (cloud) altyapısı seçilirken, projenin teknik gereksinimleri, ekibin uzmanlık düzeyi ve coğrafi hedef pazarlar göz önünde bulundurulmalıdır. Sektörün en büyük üç aktörü olan Amazon Web Services (AWS), Microsoft Azure ve Google Cloud Platform (GCP), küresel ölçekte hizmet veren kurumsal uygulamalar için standart haline gelmiştir. AWS, sunduğu yüzlerce farklı servis, devasa dökümantasyon ağı ve dünya genelindeki geniş veri merkezi yaygınlığı (Availability Zones) ile en çok tercih edilen platformdur. Özellikle sanal sunucular için Amazon EC2, konteyner yönetimi için Amazon ECS/EKS ve ilişkisel veritabanları için Amazon RDS, mobil backend altyapılarının omurgasını oluşturur.

Microsoft Azure, özellikle kurumsal ekosistemde Microsoft teknolojilerini (C#, .NET Core, SQL Server, Active Directory) kullanan ve mevcut kurumsal lisans anlaşmaları olan şirketler için doğal bir seçimdir. Hibrit bulut senaryolarında ve Windows tabanlı kurumsal entegrasyonlarda yüksek performans gösterir. Google Cloud Platform (GCP) ise Kubernetes (Google Kubernetes Engine - GKE) teknolojisinin yaratıcısı olarak konteynerize edilmiş modern mikroservis mimarilerinde benzersiz bir yönetim kolaylığı ve ağ hızı sunar. Ayrıca büyük veri analitiği (BigQuery) ve yapay zeka/makine öğrenmesi entegrasyonlarında (Vertex AI) rakiplerinin önündedir. Bulut sağlayıcı seçiminde maliyet optimizasyonu yapmak amacıyla, "Pay-as-you-go" (Kullandığın kadar öde) modelinde kalmak, geliştirme aşamasında "Spot Instances" (AWS'nin atıl sunucuları ucuza kiralaması) kullanmak ve üretim (production) ortamı için taahhütlü indirim programlarından (AWS Savings Plans gibi) faydalanmak kurumsal bütçe yönetiminin temel taşlarıdır.

Yüksek Kullanılabilirlik (High Availability) ve Yük Dengeleme (Load Balancing)

Bir mobil uygulamanın başarısı, kullanıcıların uygulamayı açtıklarında milisaniyeler içinde yanıt alabilmeleri ve uygulamanın asla çevrimdışı kalmamasıyla doğrudan ilişkilidir. Tek bir sunucu üzerine kurulan backend sistemleri, o sunucunun donanım arızası, işletim sistemi güncellemesi veya ani trafik yüklenmeleri nedeniyle çökmesi durumunda tüm uygulamanın devre dışı kalmasına yol açar. Bu riski bertaraf etmek amacıyla, "Yüksek Kullanılabilirlik" (High Availability - HA) ve "Yük Dengeleme" (Load Balancing) mimarileri kurulmalıdır. Yüksek kullanılabilirlik sağlamak için backend servisleri, bulut sağlayıcının farklı fiziksel veri merkezlerinde (Multi-AZ / Çoklu Erişilebilirlik Bölgesi) çalışan en az iki bağımsız sanal sunucu örneği (instance) üzerinde çalıştırılmalıdır.

Bu çoklu sunucu yapısının önüne yerleştirilecek bir Yük Dengeleyici (AWS Application Load Balancer - ALB, Nginx, HAProxy), mobil cihazlardan gelen tüm HTTPS isteklerini karşılar ve bu istekleri arkadaki sağlıklı sunuculara belirli algoritmalar (Round Robin, Least Connections vb.) çerçevesinde dengeli bir şekilde dağıtır. Yük dengeleyici, "Health Check" (Sağlık Kontrolü) mekanizması sayesinde arkadaki sunucuları sürekli ping'ler; eğer sunuculardan biri çökerse, trafiği anında diğer sağlıklı sunuculara yönlendirerek kullanıcılara kesintisiz hizmet sunulmasını sağlar. Ayrıca, ani trafik patlamalarında sunucu kaynaklarının tükenmesini önlemek adına "Auto-Scaling" (Otomatik Ölçeklendirme) kuralları tanımlanmalıdır. Örneğin, sunucuların ortalama CPU kullanımı %70'i aştığında, bulut paneli otomatik olarak yeni bir sunucu örneği oluşturup yük dengeleyicinin arkasına ekler; trafik azaldığında ise bu sunucuları kapatarak gereksiz maliyet oluşumunu engeller.

Veritabanı Tasarımı ve Veri Modelleme Stratejileri

Veri Bütünlüğü İçin İlişkisel Veritabanları (PostgreSQL, MySQL)

Mobil uygulamalarda finansal işlemler, sipariş yönetimi, kullanıcı üyelik bilgileri ve roller gibi veri bütünlüğünün (data integrity) kritik olduğu senaryolarda İlişkisel Veritabanı Yönetim Sistemleri (RDBMS) kullanılmalıdır. İlişkisel veritabanları, verileri satır ve sütunlardan oluşan katı şemalı tablolarda saklar ve tablolar arasındaki ilişkileri yabancı anahtarlar (foreign keys) yardımıyla kurar. Bu sistemlerin en temel gücü, ACID (Atomicity, Consistency, Isolation, Durability) standartlarını tam olarak desteklemeleridir. ACID sayesinde, bir kullanıcının cüzdanından para düşmesi ve bu paranın başka bir hesaba aktarılması gibi çok adımlı işlemler (transactions) ya tamamen başarılı olur ya da en ufak bir hata anında sistem eski güvenli haline geri döndürülür (rollback).

PostgreSQL, modern mobil uygulama backend projelerinde en çok tavsiye edilen ilişkisel veritabanıdır. Tamamen açık kaynaklı olmasının yanı sıra, karmaşık SQL sorgularını son derece performanslı çalıştırabilmesi, JSONB veri tipi desteği sayesinde yarı-yapılandırılmış NoSQL benzeri verileri de verimli bir şekilde saklayabilmesi ve zengin indeksleme (GIN, GiST, B-Tree) yetenekleri PostgreSQL'i benzersiz kılar. İlişkisel veritabanı tasarlanırken normalizasyon (1NF, 2NF, 3NF) kurallarına dikkat edilmeli, veri tekrarları önlenmeli ancak mobil uygulamadaki sorgu hızını artırmak amacıyla aşırı JOIN işlemlerinden kaçınacak şekilde kontrollü denormalizasyon adımları da atılabilmelidir. Sık sorgulanan sütunlar üzerinde indeks (index) tanımlanması, veritabanı okuma performansını binlerce kat artırabilecek en kritik optimizasyon adımıdır.

Esneklik ve Hız Odaklı Yapılar İçin NoSQL Çözümleri (MongoDB, Redis)

Sohbet geçmişleri, sosyal medya akışları, ürün katalogları, kullanıcı etkinlik logları veya anlık konum verileri gibi ilişkisel olmayan, dinamik, hızlı değişen ve yüksek yazma (write) hızı gerektiren senaryolarda NoSQL (Not Only SQL) veritabanları öne çıkar. NoSQL veritabanları katı şemalar (schemas) yerine doküman tabanlı (JSON benzeri), anahtar-değer (key-value), kolon aileli veya grafik tabanlı veri modelleri kullanır. MongoDB, doküman tabanlı NoSQL veritabanları arasında en popüler olanıdır. Her kullanıcının profil ayarlarının veya bildirim tercihlerinin farklı olabileceği senaryolarda, esnek şema yapısı sayesinde her kaydın (document) farklı alanlar içermesine izin vererek yazılım ekibine müthiş bir esneklik kazandırır.

NoSQL dünyasının mobil backend için vazgeçilmez bir diğer oyuncusu ise bellekte (in-memory) çalışan ve anahtar-değer yapısına sahip olan Redis'tir. Redis, verileri sabit disk yerine doğrudan RAM üzerinde tuttuğu için mikrosaniye düzeyinde okuma ve yazma hızlarına ulaşır. Mobil uygulamalarda Redis; sık değişmeyen ama çok sık sorgulanan verilerin (örneğin popüler ürün listeleri, şehir listeleri) önbelleğe alınmasında (caching), kullanıcı oturum (session) yönetimi verilerinin saklanmasında, API istek sınırlandırma (rate limiting) sayaçlarının tutulmasında ve gerçek zamanlı liderlik tablolarının (leaderboard) oluşturulmasında kullanılır. Modern bir kurumsal backend mimarisinde, işlem geçmişleri için PostgreSQL, dinamik içerikler için MongoDB ve hız/önbellekleme katmanı için Redis'in bir arada kullanıldığı hibrit mimariler (polyglot persistence) yaygın olarak uygulanır.

Veritabanı Ölçeklendirme ve Yedekleme (Disaster Recovery) Planlaması

Uygulamanın aktif kullanıcı sayısı yüz binlere veya milyonlara ulaştığında veritabanı üzerindeki yük katlanarak artar. Bu yükü yönetebilmek için iki temel ölçekleme yöntemi bulunur: dikey ölçekleme (vertical scaling) ve yatay ölçekleme (horizontal scaling). Dikey ölçekleme, veritabanının çalıştığı sunucunun CPU, RAM ve SSD kapasitelerini artırmaktır. Ancak dikey ölçeklemenin hem donanımsal hem de maliyet açısından fiziksel sınırları vardır. Bu sınırları aşmak için yatay ölçekleme devreye alınır. İlişkisel veritabanlarında yatay ölçekleme genellikle "Read Replicas" (Okuma Kopyaları) yapısıyla çözülür. Bu mimaride, veri yazma (write) ve güncelleme işlemleri tek bir ana veritabanı sunucusunda (Master/Primary) yapılırken; bu sunucudaki veriler eşzamanlı (synchronous) veya asenkron (asynchronous) olarak birden fazla okuma sunucusuna (Replica/Secondary) kopyalanır. Mobil uygulamadan gelen yoğun veri okuma (read) istekleri bu kopyalara yönlendirilerek ana sunucunun yükü hafifletilir. NoSQL veritabanlarında ise veri kümeleri "Sharding" (Verinin belirli kurallara göre parçalanarak farklı sunucularda saklanması) yöntemiyle yatayda kolayca ölçeklendirilebilir.

Veri kaybı, bir işletmenin karşılaşabileceği en büyük finansal ve prestij kaybı risklerinden biridir. Bu nedenle kurumsal bir backend altyapısında "Disaster Recovery" (Felaket Kurtarma) planı eksiksiz yapılandırılmalıdır. Bu plan kapsamında iki temel metrik tanımlanır:

1. RPO (Recovery Point Objective - Kurtarma Noktası Hedefi): Bir felaket anında geriye dönük en fazla kaç dakikalık/saatlik veri kaybının kabul edilebileceğini gösterir (Örneğin, her saat başı alınan yedekler RPO'yu maksimum 1 saat yapar).

2. RTO (Recovery Time Objective - Kurtarma Süresi Hedefi): Sistemin çökmesi durumunda, yedeklerin ayağa kaldırılıp uygulamanın tekrar çalışır hale getirilmesi için gereken maksimum süreyi ifade eder.

AWS RDS gibi yönetilen servisler, otomatik günlük anlık yedekleme (automated snapshots) ve Point-in-Time Recovery (belirli bir ana geri dönebilme) özelliklerini dahili olarak sunar. Ayrıca, fiziksel bir veri merkezinin tamamen yok olması riskine karşı, yedeklerin farklı bir coğrafi bölgedeki (Cross-Region) veri depolama alanlarına (AWS S3 vb.) otomatik olarak aktarılması ve yılda en az bir kez felaket senaryosu simülasyonu yapılarak yedeklerin geri yüklenebildiğinin test edilmesi teknik bir zorunluluktur.

İletişim Katmanı: API Geliştirme ve Standartlaştırma

RESTful API Mimarisi ve Kurumsal Standartlar

Mobil uygulamanın (iOS, Android, Flutter, React Native vb.) sunucudaki verilere erişmesi, yeni kayıt oluşturması veya işlemleri tetiklemesi, iki taraf arasındaki ortak dili oluşturan API (Application Programming Interface) katmanı üzerinden gerçekleşir. API geliştirmede küresel kurumsal standart, HTTP protokolü üzerinde çalışan REST (Representational State Transfer) mimarisidir. RESTful API'lerin sürdürülebilir, anlaşılır ve hatasız çalışabilmesi için katı bir standardizasyon uygulanmalıdır. Bu standartların başında HTTP metotlarının amacına uygun kullanımı gelir. Örneğin; veri çekmek için sadece GET, yeni veri oluşturmak için POST, mevcut veriyi tamamen güncellemek için PUT, verinin bir kısmını değiştirmek için PATCH ve veri silmek için DELETE metotları kullanılmalıdır.

İstemciye dönen yanıtların HTTP durum kodları (status codes) ile standartlaştırılması, mobil tarafındaki geliştiricinin hata yönetimini doğru yapabilmesi için şarttır. Başarılı işlemler için 200 veya 201 dönülürken; kullanıcı hatalarında 400, yetkisiz erişimlerde 401 veya 403, kaynak bulunamadığında 404 ve sunucu tarafında beklenmedik bir çökme yaşandığında 500 Internal Server Error kodları dönülmelidir. JSON (JavaScript Object Notation) formatındaki veri şemaları (payloads) hem istek hem de yanıt süreçlerinde tutarlı olmalı; örneğin bir hata yanıtı dönerken hata kodu, teknik açıklama ve kullanıcıya gösterilecek mesaj her uç noktada (endpoint) aynı JSON formatında iletilmelidir. Ayrıca RESTful API'lerin "Stateless" (Durumsuz) olması gerekir; yani sunucu her isteği bağımsız bir işlem olarak ele almalı, istemcinin oturum durumunu sunucu belleğinde (session state) tutmamalıdır. Bu kural, API'lerin arkasında duran sunucuların yük dengeleyici tarafından yatayda sınırsızca ölçeklendirilebilmesini sağlar.

Kompleks Veri Yönetimi İçin GraphQL Entegrasyonu

RESTful API'ler basit veri yapıları için mükemmel çalışsa da, karmaşık ilişkisel veri yapılarına sahip mobil uygulamalarda ciddi ağ ve performans sorunlarına yol açabilir. Bu sorunların en önemlileri "Over-fetching" (Gerekenden fazla veri çekilmesi) ve "Under-fetching" (Gerekenden az veri çekilmesi nedeniyle ardışık API istekleri yapılması) durumlarıdır. Örneğin, bir mobil uygulamanın ana sayfasında kullanıcının adı, profil resmi ve son 3 gönderisinin başlığı gösterilecek olsun. REST mimarisinde bu bilgiyi almak için önce /api/users/{id} uç noktasına istek atılarak kullanıcının tüm profil verileri çekilir, ardından kullanıcının gönderi ID'leri alınarak /api/posts?user_id={id} uç noktasına ikinci bir istek atılır. Bu süreç hem mobil cihazın batarya ve hücresel veri tüketimini artırır hem de sunucu üzerinde gereksiz ağ trafiği oluşturur.

Facebook tarafından geliştirilen GraphQL, bu soruna istemci merkezli bir çözüm getirir. GraphQL mimarisinde tek bir akıllı uç nokta (/graphql) bulunur ve mobil istemci, sunucuya gönderdiği sorguda (query) tam olarak hangi alanları, hangi derinlikte almak istediğini açıkça beyan eder. Sunucu, bu spesifik isteğe göre veritabanından sadece talep edilen alanları çeker ve tam olarak o şemada bir JSON yanıtı döner. Böylece tek bir ağ isteği (request roundtrip) ile tüm kompleks ve ilişkili veriler minimum boyutla (payload size) mobil cihaza iletilir. Bu, özellikle internet bağlantısının zayıf olduğu mobil ağlarda uygulamanın tepki süresini (response latency) dramatik ölçüde düşürür. Ancak GraphQL entegrasyonu, backend tarafında karmaşık sorguların (N+1 query problemi) veritabanını kilitlememesi için "DataLoader" gibi önbellekleme ve toplu sorgulama (batching) kütüphanelerinin kullanılmasını ve kötü niyetli kullanıcıların sunucuyu çökertmesini önlemek için sorgu derinliği sınırlaması (query depth limiting) middleware yapılarının kurulmasını gerektirir.

API Sürüm Yönetimi (Versioning) ve Dokümantasyon Riskleri

Web sitelerinin aksine, mobil uygulamalar yayınlandıktan sonra kullanıcıların cihazlarında eski sürümleriyle kalmaya devam eder. Bir web sitesini güncellediğinizde tüm kullanıcılar tarayıcılarını yenileyerek anında yeni kodları yükler. Ancak mobil dünyada, kullanıcıların otomatik güncellemeleri kapatmış olması veya eski işletim sistemine sahip cihazlar kullanması nedeniyle, uygulamanızın 2 yıl önce yayınlanmış olan "v1.0" sürümü hala canlı sunucunuza API istekleri atıyor olabilir. Eğer backend ekibi, yeni bir özellik geliştirirken API şemalarını değiştirir ve eski uç noktaları devre dışı bırakırsa veya çıktı formatlarını bozarsa (breaking changes), binlerce kullanıcının uygulaması anında çöker veya çalışmaz hale gelir.

Bu kritik riski yönetmek için API Sürüm Yönetimi (Versioning) zorunludur. En yaygın ve sürdürülebilir sürümleme yöntemi, URI tabanlı sürümlemedir (Örneğin: /api/v1 ve /api/v2). Bu sayede, v2 API'sine geçildiğinde yeni özellikler ve değişen veri şemaları v2 altında geliştirilirken, eski mobil uygulamalara hizmet veren v1 uç noktaları geriye dönük uyumluluk (backward compatibility) çerçevesinde dokunulmadan çalıştırılmaya devam eder. API'lerin frontend, mobil ve test ekipleri arasında bir "sözleşme" (contract) olarak kalabilmesi için güncel dökümantasyon hayati önem taşır. Kod tabanından otomatik olarak üretilen OpenAPI / Swagger dökümantasyon araçları kullanılmalı, her uç noktanın kabul ettiği parametreler, veri tipleri ve olası hata yanıt şablonları anlık olarak dökümante edilmelidir. Güncellenmemiş bir API dökümantasyonu, mobil geliştiricilerin yanlış uç noktalara istek atarak zaman kaybetmesine ve uygulamanın çıkış sürecinin (release) aksamasına neden olan en büyük teknik risklerden biridir.

Güvenlik Protokolleri ve Yasal Uyumluluk (Kritik Aşama)

Kimlik Doğrulama ve Yetkilendirme (OAuth 2.0, JWT Yönetimi)

Mobil uygulama backend altyapısının en çok siber saldırıya maruz kalan ve en hassas katmanı, kullanıcıların kimliklerini doğruladığı (Authentication) ve kaynaklara erişim izinlerinin denetlendiği (Authorization) güvenlik katmanıdır. Geleneksel web uygulamalarında kullanılan çerez tabanlı (Cookie/Session) kimlik doğrulama modelleri, mobil platformların yapısı gereği (Cross-Origin kısıtlamaları ve mobil SDK'ların çerez yönetim zorlukları) mobil uygulamalar için uygun değildir. Mobil dünyada endüstri standardı, durumsuz (stateless) çalışan Token Tabanlı Kimlik Doğrulama (Token-based Authentication) ve JWT (JSON Web Token) kullanımıdır.

JWT mimarisinde, kullanıcı kullanıcı adı ve şifresiyle sisteme giriş yaptığında, sunucu kullanıcı bilgilerini içeren ve kendi gizli anahtarı (secret key) ile imzaladığı kriptografik bir token üretip mobil cihaza gönderir. Mobil cihaz bu token'ı sonraki her API isteğinin HTTP başlığına (Authorization: Bearer <token>) ekleyerek sunucuya gönderir. Sunucu, veritabanına sorgu atmak zorunda kalmadan sadece kendi imzasını doğrulayarak isteğin güvenilir olduğunu anlar. JWT yönetiminde en kritik nokta token ömrüdür. Çalınma riskine karşı "Access Token" ömürleri çok kısa tutulmalı (örneğin 15 dakika); bunun yanında kullanıcının sürekli şifre girmesini önlemek için güvenli bir şekilde saklanan ve yeni Access Token üretilmesini sağlayan uzun ömürlü "Refresh Token" (örneğin 30 gün) kullanılmalıdır. Sosyal ağlar üzerinden (Apple, Google, Facebook ile Giriş Yap) veya kurumsal sitemlerde tek tıkla giriş (SSO) sağlamak için ise yetkilendirme delegasyon standardı olan OAuth 2.0 protokolü entegre edilmelidir. Mobil istemci tarafında bu token'lar asla düz metin (plain text) olarak veya SharedPreferences/LocalStorage içinde saklanmamalı; iOS için Keychain Services, Android için ise Android Keystore sistemleri kullanılarak donanım seviyesinde şifrelenmiş alanlarda korunmalıdır.

Veri Şifreleme (At Rest & In Transit) ve SSL/TLS Uygulamaları

Mobil backend altyapısında veriler iki durumda da mutlak suretle şifrelenmiş olmalıdır: hareket halindeyken (in transit) ve durağan haldeyken (at rest). Mobil cihaz ile sunucu arasındaki tüm veri trafiği, internet servis sağlayıcıları veya güvensiz halka açık Wi-Fi ağları üzerinden aktığı için siber saldırganlar tarafından dinlenebilir (packet sniffing). Bu riski önlemek için tüm API iletişimi HTTPS protokolü altında en az TLS 1.2 veya tercihen TLS 1.3 standartlarında şifrelenmelidir. Sadece HTTPS kullanmak da tek başına yeterli değildir; siber saldırganların araya sahte bir SSL sertifikası sokarak verileri deşifre etmesini önlemek amacıyla (Man-in-the-Middle - MitM saldırıları), mobil uygulamada "SSL/Certificate Pinning" (Sertifika Sabitleme) teknolojisi uygulanmalıdır. Bu teknoloji, mobil uygulamanın sadece kodun içine gömülmüş olan spesifik SSL sertifikası parmak izine (fingerprint) sahip olan sunucuyla konuşmasını zorunlu kılar.

Durağan haldeki verilerin (data at rest) şifrelenmesi ise sunucuların, disklerin veya veritabanı yedeklerinin fiziksel veya dijital olarak ele geçirilmesi ihtimaline karşı alınan bir önlemdir. Veritabanının üzerinde çalıştığı tüm disk hacimleri (volumes), bulut sağlayıcının anahtar yönetim servisleri (AWS KMS, Azure Key Vault vb.) entegrasyonuyla AES-256 şifreleme algoritması kullanılarak şifrelenmelidir. Kullanıcı şifreleri veritabanında asla düz metin olarak veya geri döndürülebilir şifreleme yöntemleriyle saklanmamalıdır; bunun yerine her kullanıcıya özel bir rastgele veri (salt) eklenerek Argon2id veya bcrypt gibi yüksek işlem maliyetli, tek yönlü kriptografik hashleme algoritmalarıyla şifrelenerek kaydedilmelidir.

KVKK ve GDPR Uyumluluğu Kapsamında Veri Gizliliği Sağlama

Küresel pazarda hizmet veren (GDPR) veya Türkiye pazarında faaliyet gösteren (KVKK) mobil uygulamaların yasal mevzuatlara ve veri gizliliği standartlarına uyum sağlaması hukuki ve teknik bir zorunluluktur. Bu regülasyonlar, backend mimarisinin tasarım aşamasından itibaren veri gizliliğini merkeze almasını (Privacy by Design) gerektirir. İlk olarak, "Veri Minimizasyonu" prensibi uygulanmalıdır; yani backend, uygulamanın çalışması için kesinlikle zorunlu olmayan hiçbir kişisel veriyi (PII - Personally Identifiable Information) istemciden talep etmemeli ve saklamamalıdır. Kullanıcıların adı, soyadı, T.C. kimlik numarası, e-posta adresi, telefon numarası ve konum geçmişi gibi hassas kişisel veriler veritabanında şifreli (encrypted) olarak tutulmalıdır.

Yasal uyumluluğun bir diğer ayağı, veri barındırma coğrafyasıdır. KVKK kapsamında, Türkiye'deki kullanıcıların hassas kişisel verilerinin açık rıza olmaksızın yurt dışındaki bulut sunucularına (örneğin AWS'nin Frankfurt veri merkezine) aktarılması ciddi yasal cezalara yol açabilir. Bu nedenle, projelerin yasal kapsamına göre veritabanlarının Türkiye sınırları içerisindeki yerel bulut sağlayıcılarında veya on-premise veri merkezlerinde barındırılması gerekebilir. Ayrıca backend, kullanıcılara "Unutulma Hakkı" (Right to be Forgotten) tanımalıdır. Kullanıcı mobil uygulamadan "Hesabımı Sil" butonuna bastığında, backend altyapısı kullanıcının kişisel verilerini ilişkili tüm veritabanlarından, yedekleme sunucularından ve Redis gibi önbellek katmanlarından kalıcı olarak silmeli (veya geri döndürülemez şekilde anonimleştirmeli) ve bu işlemin sorunsuz yapıldığını yasal olarak loglamalıdır.

Siber Saldırılara (DDoS, SQL Injection) Karşı Önleyici Tedbirler

Mobil uygulamaların API uç noktaları, internete açık kapılar oldukları için sürekli olarak bot ağları, otomatik tarayıcılar ve kötü niyetli aktörlerin hedefindedir. En sık karşılaşılan saldırı türlerinden biri olan DDoS (Distributed Denial of Service) saldırıları, sunucu kaynaklarını ve ağ bant genişliğini tüketerek uygulamayı çalışamaz hale getirmeyi amaçlar. Bu saldırıları engellemek için sunucu altyapısının önüne Cloudflare, AWS Shield veya GCP Cloud Armor gibi Web Uygulaması Güvenlik Duvarı (WAF) ve DDoS koruma katmanları yerleştirilmelidir. WAF, gelen şüpheli bot trafiğini filtreler ve sunuculara ulaşmadan engeller. Ayrıca, API uç noktalarına IP veya kullanıcı ID'si bazında "Rate Limiting" (İstek Sınırlandırma) uygulanmalıdır; örneğin bir IP adresinden saniyede en fazla 10 API isteği atılmasına izin verilmeli, bu limiti aşan istemcilere otomatik olarak 429 Too Many Requests hatası dönülmelidir.

Uygulamanın kod seviyesindeki en tehlikeli açıklarından biri ise SQL Injection (SQLi) sızıntılarıdır. Kötü niyetli bir kullanıcının arama kutusuna veya giriş alanına yazdığı özel karakterlerle veritabanı sorgularını manipüle etmesini önlemek amacıyla, backend tarafında veritabanı sorguları yazılırken ham (raw) SQL sorguları yerine mutlaka ORM (Object-Relational Mapping; örn. Prisma, TypeORM, SQLAlchemy) kütüphaneleri kullanılmalı ve parametrik sorgular (parameterized queries) tercih edilmelidir. Sunucuya gelen her veri, API uç noktasına girmeden önce sıkı bir girdi validasyonuna (input validation) tabi tutulmalıdır. OWASP (Open Web Application Security Project) tarafından her yıl güncellenen "Mobile Top 10" ve "API Security Top 10" siber güvenlik listeleri, backend geliştirme ekibi tarafından bir başucu rehberi olarak kabul edilmeli ve yılda en az bir kez bağımsız siber güvenlik firmalarına "Sızma Testi" (Penetration Testing) yaptırılarak olası sistem açıkları canlı ortama geçmeden önce kapatılmalıdır.

Test, Sürekli Entegrasyon ve Canlıya Alma (CI/CD)

Birim (Unit), Entegrasyon ve Yük (Stress) Testlerinin Önemi

Yazılan backend kodlarının üretim (production) ortamına, yani gerçek kullanıcıların karşısına çıkarılmadan önce kalitesinin, doğruluğunun ve performans sınırlarının ölçülmesi gerekir. Manuel olarak yapılan "postman ile istek atıp deneme" yöntemleri, karmaşıklaşan kurumsal sistemlerde yeni eklenen özelliklerin eski özellikleri bozup bozmadığını tespit edemez. Bu nedenle, yazılım mimarisinin ilk gününden itibaren otomatik test kültürü benimsenmelidir. İlk katman olan Birim Testleri (Unit Tests), kod tabanındaki en küçük işlevsel birimlerin (fonksiyonlar, yardımcı sınıflar) dış dünyadan ve veritabanından izole edilerek test edilmesidir (Mocking). Örneğin, bir indirim kuponunun son kullanma tarihini hesaplayan fonksiyonun doğruluğu yüzlerce farklı senaryo ile milisaniyeler içinde birim testler vasıtasıyla doğrulanır.

İkinci katman olan Entegrasyon Testleri (Integration Tests) ise, sistem bileşenlerinin bir arada uyum içinde çalışıp çalışmadığını ölçer. Bir entegrasyon testi, test ortamında gerçek bir veritabanı ayağa kaldırarak "kullanıcı kayıt API'sine istek gönderildiğinde şifrenin hash'lenip hash'lenmediğini, veritabanına yeni satır yazılıp yazılmadığını ve başarılı dönüş yapılıp yapılmadığını" baştan sona simüle eder. Mobil backend projeleri için hayati önem taşıyan son katman ise Yük (Stress/Load) Testleridir. Uygulama marketlerinde öne çıkan veya büyük bir kampanya yapacak olan bir mobil uygulamanın sunucuları, anlık olarak on binlerce kullanıcıyı karşılamak zorundadır. k6, Apache JMeter veya Locust gibi araçlar kullanılarak yapılan yük testleri ile sunuculara yapay bir trafik yüklenir; sistemin kaç eşzamanlı kullanıcıdan (concurrent users) sonra yanıt vermeyi bıraktığı, veritabanı kilitlenmeleri (deadlocks) veya bellek sızıntıları (memory leaks) canlıya alım öncesinde tespit edilerek gerekli performans optimizasyonları yapılır.

DevOps Süreçleri: Kesintisiz ve Güvenli Deployment Otomasyonu

Geliştirilen backend kodlarının sunuculara yüklenmesi, konfigüre edilmesi ve canlıya alınması süreçlerinin manuel olarak yapılması (örneğin sunucuya SSH ile bağlanıp git pull yapmak), insan hatasına son derece açık, yavaş ve güvensiz bir yöntemdir. Kurumsal standartlarda bu süreç, CI/CD (Continuous Integration / Continuous Deployment - Sürekli Entegrasyon ve Sürekli Dağıtım) boru hatları (pipelines) vasıtasıyla tamamen otomatik hale getirilir. Geliştirici ekip, yeni bir kodu ana depoya (GitHub, GitLab, Bitbucket) gönderdiği (push) anda CI/CD boru hattı tetiklenir.

İlk aşamada (CI), kod kalitesi standartlarını denetleyen statik kod analiz araçları (linters) çalıştırılır, kod güvenlik açıklarına karşı taranır ve ardından otomatik birim ve entegrasyon testleri koşturulur. Eğer testlerden biri dahi başarısız olursa, kodun canlıya geçişi otomatik olarak durdurulur ve geliştiriciye hata bildirimi gönderilir. Tüm testlerin başarıyla tamamlanması durumunda CD aşaması devreye girer. Modern dağıtım süreçlerinde backend uygulamaları Docker konteynerleri (containers) haline getirilir. Docker, uygulamanın çalışması için gereken tüm kütüphaneleri, çalışma ortamını ve kodları tek bir paket haline getirerek "geliştiricinin bilgisayarında çalışan ama sunucuda çöken" uyumsuzluk problemlerini tamamen ortadan kaldırır. Konteynerleştirilen uygulama, Kubernetes (K8s), AWS ECS veya GCP Cloud Run gibi orkestrasyon araçları vasıtasıyla sunucu havuzuna dağıtılır. Kesintisiz canlıya alım sağlamak için "Blue-Green Deployment" veya "Canary Release" yöntemleri kullanılır. Blue-Green yönteminde, yeni sürüm (Green) tamamen ayrı bir sunucu grubuna kurulup test edildikten sonra, yük dengeleyici üzerindeki tüm trafik tek bir tıkla eski sürümden (Blue) yeni sürüme aktarılır; bir sorun yaşanması durumunda ise anında eski sürüme geri dönülebilir (rollback).

---