Backend/API Mimarisi Kurarken İlk Günden Doğru Karar Vermek

İki yıl önce büyümesi hızlı giden bir müşterimizin sistemi, kullanıcı sayısı 5 bine ulaştığında çökmeye başlamıştı. Sorun sunucu gücü değildi; veritabanı sorgularının hepsi ilişkisel tablolarda index'siz JOIN'ler üzerine kuruluydu. Mimari kararlar erken alınır, bedeli geç ödenir — backend tasarımında en sık gördüğümüz durum bu.

REST API'de basitlik disiplindir

REST API tasarlarken kaynak (resource) odaklı düşünmek işi kolaylaştırır: /users, /orders/{id}/items gibi net, öngörülebilir endpoint isimleri. Fiil değil isim kullanmak, HTTP metodlarını (GET, POST, PUT, DELETE) doğru semantiğiyle kullanmak küçük bir detay gibi görünse de, uygulamayı geliştiren mobil ekip için büyük fark yaratıyor. Versiyonlama da (/api/v1/...) en başta düşünülmeli; yayına çıktıktan sonra API'yi kırmadan değiştirmek neredeyse imkansız hale geliyor.

Veritabanı seçimi: ilişkisel mi, NoSQL mi

Çoğu ticari uygulama için PostgreSQL veya MySQL gibi ilişkisel veritabanları hâlâ doğru tercih — veri bütünlüğü, transaction desteği ve olgun ekosistem bunu destekliyor. MongoDB gibi doküman tabanlı sistemler, şeması sık değişen, hiyerarşik veri barındıran (örneğin ürün kataloğu, form builder gibi) senaryolarda avantajlı. Ama "NoSQL daha hızlıdır" diye genel bir kural yok; yanlış senaryoda kullanıldığında sorgu karmaşıklığı ilişkisel veritabanına göre çok daha fazla artabiliyor.

Ölçeklenebilirlik: erken düşün, erken abartma

Günde 200 kullanıcısı olacak bir uygulama için mikroservis mimarisi kurmak, gereksiz karmaşıklık ve maliyet demek. Buna karşılık, ileride büyümesi beklenen bir platformda stateless API tasarımı (oturum bilgisini sunucu belleğinde değil, token içinde taşımak) yapmak, yatay ölçeklenmeyi kolaylaştıran ucuz bir erken karar. Caching katmanı (Redis gibi) sık okunan, az değişen veriler için baştan planlanmalı; sonradan eklemek mimari değişiklik gerektirebiliyor.

Mobil tarafla uyum

Backend tasarlanırken Android ve iOS tarafının network kısıtlarını hesaba katmak gerekiyor: mobil bağlantı kopabilir, istekler tekrar gönderilebilir. Idempotent endpoint tasarımı (aynı isteğin iki kez gönderilmesi durumunda veri tekrarlanmaması) bu yüzden önemli. Pagination'ı da baştan kurmak lazım — binlerce kaydı tek seferde döndüren bir endpoint, hem sunucuyu hem mobil uygulamayı yorar.

Loglama ve izlenebilirlik

Hata ayıklamak için production ortamında yeterli log tutmak, ama kişisel veriyi loglara yazmamak arasında ince bir denge var. Her isteğe bir request ID atamak, hata durumunda hangi isteğin nerede takıldığını saniyeler içinde bulmayı sağlıyor. Bunu sonradan eklemek, mevcut kod tabanına dokunmadan yapılamıyor; bu yüzden ilk günden standart olarak kurulmalı.

Backend mimarisi, projenin görünmeyen ama en kritik parçası. Mobil uygulama fiyatları konuşulurken çoğu zaman arayüz öne çıkar ama sağlam bir API katmanı olmadan hiçbir mobil uygulama uzun vadede ayakta kalamaz.

Backend Mimarisi Mobil Uygulama Ölçeklenebilirlik REST API Veritabanı