Mobil sistem tasarımı mülakatı, backend sistem tasarımı sorularından farklı bir düşünme biçimi ister: sunucu tarafında yatay ölçeklenme ve veritabanı şeması konuşulurken, mobilde pil, kesintili ağ bağlantısı, işletim sisteminin dayattığı arka plan kısıtları ve tek bir cihazın sınırlı kaynakları öne çıkar. Bu yazıda mobil sistem tasarımının backend'den beş temel farkını, altı gerçek soru tipini (haber akışı, çevrimdışı senkronizasyon, sohbet, gerçek zamanlı güncelleme, dosya yükleme, arka plan işleri) ve cevabını yapılandırma iskeletini; Android'in resmi mimari rehberi ile Apple'ın BackgroundTasks dokümantasyonuna dayanarak ele alacağız.
💡 Pro Tip: Mülakatta önce veri akışının yönünü çiz — state aşağı, event yukarı. Sınıf isimlerine atlayıp bu akışı söze dökmemek yaygın bir tuzaktır; değerlendirici tam da bunu dinliyor.
İçindekiler
- Mobil Sistem Tasarımının Backend'den Beş Farkı
- 1. Sorumluluk ayrımı backend'den daha katı işler
- 2. Ağ bağlantısı garanti değil, kural
- 3. UI, kalıcı veri modelinden beslenir
- 4. Tek yönlü veri akışı (UDF) zorunluluğu
- 5. Arka plan çalışması sistem tarafından kısıtlanır
- Cevap İskeleti: Gereksinim, Kısıt, Veri Akışı, Ödünleşim
- Soru 1-2: Haber Akışı ve Çevrimdışı Senkronizasyon
- Soru 1: Haber akışı nasıl tasarlanır?
- Soru 2: Çevrimdışı senkronizasyon nasıl çözülür?
- Soru 3-4: Sohbet ve Gerçek Zamanlı Güncelleme
- Soru 3: Sohbet uygulaması mimarisi
- Soru 4: Gerçek zamanlı güncelleme — refresh mi, push mü?
- Soru 5-6: Dosya Yükleme ve Arka Plan İşleri
- Soru 5: Büyük dosya nasıl yüklenir?
- Soru 6: Arka plan bakım işleri (temizlik, senkron, indeksleme)
- Ödünleşimleri Sesli Düşünme Tekniği
- Sık Yapılan 5 Hata ve Toparlama Cümleleri
- SSS
- Mobil sistem tasarımı mülakatında ne soruluyor?
- Backend sistem tasarımından farkı ne?
- Cevabı nasıl yapılandırmalıyım?
- Arka plan görevleri her zaman çalışır mı?
- Hangi kaynaklara bakmalıyım?
- Güncelleme (Eylül 2026)
- Sonuç
- Kaynaklar
Mobil Sistem Tasarımının Backend'den Beş Farkı
Backend sistem tasarımı sorularında ölçeklenme ve tutarlılık (consistency) merkezdedir; mobilde ise tek bir kullanıcının cihazı, o cihazın kısıtları ve bağlantı durumu merkezdedir. Android'in resmi mimari rehberi bu farkın temelini oluşturan birkaç ilkeyi net biçimde tanımlar.
1. Sorumluluk ayrımı backend'den daha katı işler
Android mimari rehberi en temel ilke olarak "separation of concerns"i tanımlar: uygulamayı açıkça tanımlanmış sorumluluk ve sınırları olan metotlara, sınıflara, dosyalara, paketlere, modüllere ve katmanlara ayırmak. Mobilde bu ayrım yalnız kod okunabilirliği için değil, tek bir process'in yaşam döngüsü (arka plana atılma, sonlandırılma, yeniden başlatılma) yüzünden de zorunludur.
2. Ağ bağlantısı garanti değil, kural
Backend'de bir servisin diğerine ulaşamaması bir hata senaryosudur; mobilde ağ kopukluğu normal akışın bir parçasıdır. Android rehberi çevrimdışı-öncelikli uygulamalarda "verinin gerçek kaynağının tipik olarak bir veritabanı" olduğunu belirtir — yani ağ, veriyi doğrudan UI'ye taşıyan bir boru hattı değil, yerel veritabanını besleyen bir kaynaktır. Mobil sistem tasarımı sorularında bu ayrımı söylemek (network bir data source'tur, SSOT değil) art arda gelen "peki internet giderse?" sorularının çoğunu önceden cevaplar. Konuyu daha derinden işlemek istersen Network Layer Optimizasyonu yazısına bakabilirsin.
3. UI, kalıcı veri modelinden beslenir
"Diğer önemli bir ilke, UI'yi veri modellerinden, tercihen kalıcı modellerden beslemektir" der Android rehberi. Backend'de bu genelde bir API sözleşmesi meselesidir; mobilde ise UI katmanının kendisi, uygulama arka plana atılıp geri geldiğinde bile tutarlı kalması gereken bir state makinesidir.
4. Tek yönlü veri akışı (UDF) zorunluluğu
Android rehberi UDF'i şöyle tarif eder: state yalnız bir yönde akar, event'ler ters yönde akar. Mobil mülakatlarda "iki ekran aynı veriyi farklı gösteriyor" hatasının kök nedeni genellikle bu tek yönlü akışın çiğnenmesidir — state'in birden fazla yerde kopyalanması. Mimariyi katmanlara ayırırken bu akışı nasıl koruduğunu anlatmak, Clean Architecture (iOS) yazısındaki katman sınırlarıyla doğrudan örtüşür.
5. Arka plan çalışması sistem tarafından kısıtlanır
Backend'de bir cron job'un ne zaman çalışacağını sen belirlersin; mobilde bunu işletim sistemi belirler. Apple'ın BackgroundTasks dokümantasyonu bunu net söyler: "Uygulamanın en kritik işini framework tarafından sağlanan görevlere sararak arka planda işlemeyi destekle." Yani mülakatta "arka planda X'i senkronize ederim" demek yeterli değildir — hangi framework görev tipini kullanacağını ve sistemin bu görevi ne zaman/nasıl kısıtlayacağını bilmek gerekir. Bu beş farkı gövdeye yerleştirdikten sonra aday, artık backend refleksleriyle değil mobile özgü kısıtlarla düşündüğünü göstermiş olur.
Cevap İskeleti: Gereksinim, Kısıt, Veri Akışı, Ödünleşim
İyi bir mobil sistem tasarımı cevabı dört adımdan oluşan sabit bir iskelet üzerine kurulur. Bu iskelet, sorunun içeriği değişse de (haber akışı, sohbet, dosya yükleme) aynı kalır — değerlendirici bu tutarlılığı arar.
Adım | Ne sorulur | Neden önemli |
|---|---|---|
1. Gereksinim | Kaç kullanıcı, hangi platform, çevrimdışı destek şart mı? | Kapsamı daraltır, gereksiz genelleme önler |
2. Kısıt | Pil, depolama, ağ tipi (wifi/hücresel), OS sürüm aralığı | Mobile özgü sınırları öne çıkarır |
3. Veri akışı | SSOT nerede, UI oradan nasıl beslenir, event nereye gider | UDF'i somutlaştırır |
4. Ödünleşim | Hangi iki seçenek var, hangi ölçütle karar verildi | "Neden bu değil de bu" sorusuna hazırlık |
Aday bu dört adımı sesli ifade ettiği sürece, sorunun detayını tam bilmese bile "nasıl düşündüğünü" göstermiş olur — mülakatın asıl ölçtüğü de zaten budur.
Soru 1-2: Haber Akışı ve Çevrimdışı Senkronizasyon
Soru 1: Haber akışı nasıl tasarlanır?
Bu soru genelde "sonsuz kaydırmalı bir haber akışını tasarla" şeklinde gelir. İskeleti uygularsan: gereksinim (çevrimdışı okunabilir mi, kaç kaynak birleşiyor), kısıt (pil/veri tasarrufu), veri akışı (repository → local DB → UI), ödünleşim (ağdan direkt render vs. önce DB'ye yaz sonra DB'den oku). Android rehberi veri katmanını şöyle tanımlar: "Veri katmanı, sıfır ile çok sayıda veri kaynağı içerebilen repository sınıflarından oluşur ve veri kaynakları arasındaki çakışmaları çözer." Haber akışında bu, ağ kaynağı + yerel önbellek + kullanıcı tercihleri gibi birden fazla kaynağın tek bir repository arkasında birleşmesi demektir.
kotlin
1// Basitleştirilmiş repository — SSOT yerel veritabanıdır, ağ yalnız bir kaynaktır2class NewsFeedRepository(3 private val local: FeedDao,4 private val remote: FeedApi,5) {6 // UI her zaman local'den okur; ağ yalnızca local'i günceller7 fun observeFeed(): Flow<List<FeedItem>> = local.observeAll()8 9 suspend fun refresh() {10 val items = remote.fetchLatest()11 local.upsertAll(items) // çakışma burada repository seviyesinde çözülür12 }13}Soru 2: Çevrimdışı senkronizasyon nasıl çözülür?
Bu soru genelde Soru 1'in devamı olarak gelir: "peki kullanıcı çevrimdışıyken beğeni/yorum yaparsa?" Cevap iskeletini aynen uygularsın ama veri akışı adımı genişler: kullanıcı eylemi önce yerel veritabanına yazılır (SSOT), sonra bir kuyruk (outbox) üzerinden ağa gönderilir, sunucu onayı geldiğinde yerel kayıt güncellenir. Android rehberinin "offline-first uygulamalarda gerçek kaynak tipik olarak veritabanıdır" ilkesi burada doğrudan uygulanır — kullanıcı eylemi asla doğrudan ağa yazılıp UI'de "başarılı" varsayılmaz, önce yerel gerçeğe yazılır.
Ödünleşim burada nettir: senkron ağ çağrısı (basit ama kullanıcıyı bekletir, offline'da kırılır) vs. outbox + arka plan senkronu (dayanıklı ama çakışma çözümü ve idempotency gerektirir). Bu ödünleşimi sözle ifade eden aday, Clean Architecture (iOS) yazısındaki repository sınırlarını referans göstererek çakışma çözümünü hangi katmana koyduğunu da açıklamalı.
Soru 3-4: Sohbet ve Gerçek Zamanlı Güncelleme
Soru 3: Sohbet uygulaması mimarisi
Sohbet sorusunda değerlendirici genelde mesajın hem yerelde anında görünmesini (optimistic UI) hem de arka planda güvenilir şekilde gönderilmesini nasıl ayırdığını görmek ister. İskelet burada da aynı: SSOT yerel mesaj tablosu, gönderim durumu (gönderiliyor/gönderildi/başarısız) ayrı bir alan olarak modellenir, event yukarı akar (kullanıcı gönder der), state aşağı akar (mesaj listesi güncellenir).
Bu ayrımın pratikte anlamı şudur: kullanıcı gönder'e bastığı anda mesaj yerel tabloya "gönderiliyor" durumuyla yazılır ve UI anında güncellenir — kullanıcı ağ gecikmesini hiç hissetmez. Arka planda ayrı bir işleyici bu satırı okur, ağa gönderir, sonucu (başarılı/başarısız) aynı satıra geri yazar; UI bu satırı zaten dinlediği için otomatik güncellenir, ayrı bir "gönderim tamamlandı" event'i dinlemeye gerek kalmaz. Bu tasarımın en önemli faydası, uygulama arka plana atılıp öldürülse bile "gönderiliyor" durumundaki mesajların kaybolmaması, bir sonraki açılışta kaldığı yerden devam edebilmesidir — çünkü durum event'te değil, kalıcı veride tutulur. Mülakatta bu noktayı vurgulamak, "neden event değil de veri modeli" sorusuna hazır bir cevap sağlar: event geçicidir, process öldüğünde kaybolur; veri modeli kalıcıdır.
Soru 4: Gerçek zamanlı güncelleme — refresh mi, push mü?
Burada aday sık sık "periyodik yenileme yeterli mi, yoksa push/socket mi gerekir?" sorusuyla karşılaşır. Apple'ın BackgroundTasks dokümantasyonu bu ödünleşimin bir tarafını netleştirir: "Uygulamayı arka planda küçük bilgi güncellemeleriyle (ör. güncel hisse değerleri) yenilemek için app refresh görevlerini kullan." Yani periyodik arka plan yenilemesi (BGAppRefreshTask) düşük frekanslı, küçük veri güncellemeleri için tasarlanmıştır — sohbet gibi yüksek frekanslı ve düşük gecikme gerektiren senaryolar için uygun değildir; bu senaryolarda push bildirimi + socket/long-polling tercih edilir. Ayrıca bu görevleri çalıştırmak, Info.plist'te fetch UIBackgroundModes yeteneğinin ayarlanmasını gerektirir.
swift
1// BGAppRefreshTask kaydı — düşük frekanslı yenileme için (sohbet için DEĞİL)2func registerRefreshTask() {3 BGTaskScheduler.shared.register(4 forTaskWithIdentifier: "com.example.app.refresh",5 using: nil6 ) { task in7 handleAppRefresh(task: task as! BGAppRefreshTask)8 }9}10 11func scheduleAppRefresh() {12 let request = BGAppRefreshTaskRequest(identifier: "com.example.app.refresh")13 request.earliestBeginDate = Date(timeIntervalSinceNow: 15 * 60)14 try? BGTaskScheduler.shared.submit(request)15}Mülakatta bu ayrımı (refresh görevi = küçük/periyodik, socket/push = anlık) söylemek, sistem tasarımı sorularında sık atlanan bir noktadır.
Soru 5-6: Dosya Yükleme ve Arka Plan İşleri
Soru 5: Büyük dosya nasıl yüklenir?
Bu soru genelde "kullanıcı büyük bir video seçti, uygulamadan çıksa bile yükleme devam etsin" şeklinde gelir. Apple dokümantasyonu burada BGProcessingTask'ı işaret eder: "Uzun veri güncellemeleri, veri işleme ve uygulama bakımı için processing görevlerini kullan... sistem işlemi kesintiye uğratabilir." Yani dosya yükleme, kısa bir refresh görevi değil, dakikalar sürebilen ve sistemin kesebileceği bir processing görevidir — aday bunu bilmezse "arka planda basitçe bekletirim" gibi gerçekçi olmayan bir cevaba düşer.
BGProcessingTaskRequest'in iki alanı doğrudan ödünleşimi somutlaştırır: requiresNetworkConnectivity (ağ bağlantısı gerekiyor mu) ve requiresExternalPower (harici güç gerekiyor mu).
swift
1// Büyük dosya yükleme — processing task, ağ zorunlu, güç isteğe bağlı2func scheduleUpload(fileSizeIsLarge: Bool) {3 let request = BGProcessingTaskRequest(identifier: "com.example.app.upload")4 request.requiresNetworkConnectivity = true5 request.requiresExternalPower = fileSizeIsLarge // çok büyük dosyada tercih6 try? BGTaskScheduler.shared.submit(request)7}Mülakatta "neden processing, neden refresh değil" diye sorulursa cevap nettir: refresh görevleri küçük veri için tasarlanmıştır, processing görevleri ise dakikalarca sürebilen işler için.
Soru 6: Arka plan bakım işleri (temizlik, senkron, indeksleme)
Bu soru "eski önbelleği temizle" veya "arama indeksini güncelle" gibi periyodik ama kullanıcıyı bekletmemesi gereken işleri kapsar. Apple dokümantasyonu processing görevlerinin çalışma koşulunu net söyler: "Processing görevleri yalnızca cihaz boştayken (idle) çalışır. Kullanıcı cihazı kullanmaya başlarsa sistem çalışan processing görevlerini sonlandırır; refresh görevleri bundan etkilenmez." Bu tek cümle, mülakatta sık düşülen bir tuzağı da açıklar: "arka plan bakım işim her zaman tamamlanır" varsayımı yanlıştır — iş yarıda kesilebilir, bu yüzden idempotent ve devam edebilir (resumable) tasarlanmalıdır.
text
1Görev tipi karar ağacı (Apple BackgroundTasks'a göre)2 Küçük, periyodik veri güncellemesi? -> BGAppRefreshTask3 Dakikalar sürebilen işlem/bakım? -> BGProcessingTask4 requiresNetworkConnectivity = ağ şart mı?5 requiresExternalPower = büyük/güç-yoğun iş mi?6 Cihaz idle değilse processing kesilir -> iş idempotent olmalıBu iki görev tipini (refresh/processing) ve iki bayrağı (ağ/güç) net biçimde ayırt eden aday, sistemin sana ne zaman izin verdiğini, ne zaman izin vermediğini bildiğini göstermiş olur — mülakatta gözden kaçan bir nokta tam da budur.
Ödünleşimleri Sesli Düşünme Tekniği
Mülakat boyunca fark yaratan davranışlardan biri, sessizce karar vermek değil, ödünleşimi yüksek sesle düşünmektir: "İki seçeneğim var, şu ölçütle karara varıyorum." Android rehberinin UDF tanımı burada da yol gösterir — "Uygulamanın tüm katmanlarında tek yönlü veri akışı, karmaşıklığı yönetmek için durum tutucularıyla (state holder) UI katmanı, coroutine ve flow'lar, dependency injection en iyi pratikleri" bir arada listelenir. Yani mimari cevabın yalnız "katman isimleri" değil, katmanlar arası akışın yönü ve bu akışı hangi araçla (coroutine/flow, state holder) yönettiğin ile değerlendirilir.
Seçenek A | Seçenek B | A ne zaman doğru | B ne zaman doğru |
|---|---|---|---|
Ağdan direkt render | Repository + yerel DB (SSOT) | Tek seferlik, çevrimdışı gereksinimi yok | Çevrimdışı okunabilirlik veya çoklu kaynak birleşimi şart |
BGAppRefreshTask | Push + socket | Küçük, periyodik güncelleme | Yüksek frekans, düşük gecikme gerekli |
Senkron ağ çağrısı | Outbox + arka plan senkron | Kullanıcı sonucu hemen görmeli, hata toleransı düşük | Çevrimdışı yazma + sonradan uzlaştırma gerekli |
Bu tabloyu ezberlemek değil, mantığını (küçük/büyük, periyodik/anlık, tek-kaynak/çoklu-kaynak) kavramak mülakatta transfer edilebilir bir beceridir. Yeni bir soru geldiğinde bu üç eksenden hangisinin devrede olduğunu (veri boyutu, zamanlama sıklığı, kaynak sayısı) belirlemek, doğru satırı tabloda aramaktan daha değerlidir — çünkü mülakat seni ezbere değil, karşına yeni bir varyasyon çıktığında aynı mantığı yeniden kurabilmene göre değerlendirir. Örneğin "büyük bir dosyayı periyodik olarak, çevrimdışıyken kuyruğa alıp bağlantı gelince yükle" sorusu, aslında yukarıdaki üç satırın bir kombinasyonudur: SSOT olarak yerel kuyruk, processing görevi olarak zamanlama, ağ bağlantısı bayrağı olarak da koşul. Bu üç ekseni birleştirebilen aday, tabloyu tek tek ezberleyen adaydan çok daha güçlü bir sinyal verir.
Sık Yapılan 5 Hata ve Toparlama Cümleleri
ALTIN İPUCU
Bu yazının en değerli bilgisi
Bu ipucu, yazının en önemli çıkarımını içeriyor.
Easter Egg
Gizli bir bilgi buldun!
Bu bölümde gizli bir bilgi var. Keşfetmek ister misin?
Okuyucu Ödülü
Mülakat gününden önce hızlıca gözden geçirebileceğin, bu yazıdaki dört adımlı iskeleti ve altı soru tipini tek sayfada toplayan bir kontrol listesi hazırladık. Aşağıdaki maddeleri mülakattan bir gece önce okuman, her birini yüksek sesle bir kez tekrar etmen yeterli.
- Hata 1 — Ağı SSOT sanmak: Aday veriyi doğrudan ağdan render eder gibi anlatır. Toparlama cümlesi: "Aslında ağ burada yalnız bir veri kaynağı, gerçek kaynak yerel veritabanı olmalı — repository bu ikisini birleştirir."
- Hata 2 — State'i birden fazla yerde kopyalamak: İki ekranın aynı veriyi farklı göstermesi. Toparlama: "Bunu tek yönlü veri akışıyla çözerim; state tek bir yerden gelir, event'ler oraya geri gider."
- Hata 3 — Processing görevinin garanti çalışacağını varsaymak: Aday "arka planda bitirir" der ama kesintiyi hesaba katmaz. Toparlama: "Processing görevi cihaz idle değilken kesilebilir, bu yüzden işi idempotent ve devam edebilir tasarlarım."
- Hata 4 — Refresh ve processing görevini karıştırmak: Büyük dosya yüklemeyi refresh görevine bağlamak. Toparlama: "Refresh küçük/periyodik veri için, processing dakikalar sürebilen işler için — burada processing kullanırım."
- Hata 5 — Ödünleşimi hiç söylememek: Tek bir çözüm sunup gerekçe atlamak. Toparlama: "İki seçeneğim vardı, şu ölçütle bu seçeneği seçtim" cümlesini her cevabın sonuna eklemek, mülakatın değerlendirdiği asıl beceriyi görünür kılar.
SSS
Mobil sistem tasarımı mülakatında ne soruluyor?
Genelde altı soru tipinden biri gelir: haber akışı benzeri liste ekranları, çevrimdışı senkronizasyon, sohbet uygulaması, gerçek zamanlı güncelleme, büyük dosya yükleme ve periyodik arka plan bakım işleri. Sorunun yüzeyi değişse de değerlendirilen şey aynıdır: veri akışını (SSOT, UDF) ve mobile özgü kısıtları (pil, ağ, arka plan izinleri) doğru sırayla düşünüp düşünmediğin.
Backend sistem tasarımından farkı ne?
Backend soruları ölçeklenme ve dağıtık tutarlılık etrafında döner; mobil sorular ise tek bir cihazın kısıtları (pil, kesintili ağ, işletim sisteminin arka plan sınırlamaları) etrafında döner. Android'in resmi mimari rehberi bu farkı "UI'yi kalıcı veri modellerinden beslemek" ve "tek yönlü veri akışı" ilkeleriyle somutlaştırır — backend'de bu kavramların karşılığı genelde önbellekleme ve mesaj kuyruklarıdır, mobilde ise yerel veritabanı ve state holder'lardır.
Cevabı nasıl yapılandırmalıyım?
Dört adımlı iskeleti sırayla uygula: önce gereksinimi netleştir, sonra kısıtları say, ardından veri akışını (SSOT'tan UI'ye, event'ten geri) çiz, son olarak seçtiğin her yol için bir ödünleşim cümlesi söyle. Bu sıra, sorunun konusu ne olursa olsun (haber akışı, sohbet, dosya yükleme) aynı kalır.
Arka plan görevleri her zaman çalışır mı?
Hayır. Apple'ın BackgroundTasks dokümantasyonuna göre processing görevleri yalnızca cihaz boştayken çalışır ve kullanıcı cihazı kullanmaya başladığında sistem tarafından sonlandırılabilir; bu yüzden bu görevler idempotent ve devam edebilir tasarlanmalıdır.
Hangi kaynaklara bakmalıyım?
Android tarafında resmi "Guide to app architecture" sayfası, Apple tarafında BackgroundTasks framework dokümantasyonu (BGTaskScheduler, BGAppRefreshTask, BGProcessingTask) en sağlam başlangıç noktalarıdır — ikisi de platformların kendi mühendislik ekipleri tarafından yazılır ve güncel tutulur.
Güncelleme (Eylül 2026)
Bu yazı 2024-10-22'de, o tarihteki Android ve Apple araçlarıyla yazıldı. Aradan geçen sürede mülakat sorularının arka planındaki gerçekler kısmen değişti, aşağıdaki dört gelişmeyi bilmek cevabına ekstra derinlik katar:
Yazının yayımlandığı günlerde yeni yürürlüğe giren ve bugün hâlâ geçerli olan bir kısıt: Android 15 (Ekim 2024) ile birlikte, API 35 (Android 15) veya üstünü hedefleyen uygulamalarda dataSync ve mediaProcessing tipi foreground service'lere 24 saatlik dilimde toplam 6 saatlik çalışma sınırı ve BOOT_COMPLETED ile başlatmaya kısıtlar geldi — yani "arka planda sürekli senkronize ederim" cevabı artık WorkManager gibi sistemin kendisinin yönettiği bir araca yaslanmalı, foreground service'e değil.
Android 16 (2025) ile, API 36'yı hedefleyen ve Android 16 veya üstü bir cihazda çalışan uygulamalarda predictive back sistem animasyonları (back-to-home, cross-task, cross-activity) varsayılan olarak etkin; bu uygulamalarda onBackPressed() çağrılmıyor ve KeyEvent.KEYCODE_BACK artık dispatch edilmiyor — bu, "gezinme state'i nerede tutulur" sorusuna yeni bir kısıt ekledi.
Google Play, yeni uygulamalar ve güncellemeler için hedef API seviyesini 31 Ağustos 2026'da API 36'ya zorunlu kıldı (uzatmayla 1 Kasım 2026); WorkManager (2.12.0) hâlâ Android'de birincil offline arka plan aracı olmaya devam ediyor.
Apple da WWDC 2025'te cihaz-üstü büyük dil modeline Swift API erişimi sağlayan Foundation Models framework'ünü tanıttı — 2024-10-22'de bu framework yoktu; günümüzde mülakatta "sistem tasarımına on-device AI nasıl girer" gibi ek bir soru katmanı oluşturabilir.
Sonuç
Mobil sistem tasarımı mülakatı, backend mülakatının küçültülmüş bir versiyonu değil, kendi kısıtları olan ayrı bir disiplindir. Dört adımlı iskeleti (gereksinim, kısıt, veri akışı, ödünleşim) her soruya uygulayıp, altı soru tipinin (haber akışı, çevrimdışı senkron, sohbet, gerçek zamanlı güncelleme, dosya yükleme, arka plan bakım) ortak paydasını — SSOT ve tek yönlü veri akışı — net biçimde anlatabilen aday, güçlü bir sinyal verir. Mimariyi katmanlara nasıl ayırdığını daha derinlemesine anlatmak istersen Clean Architecture (iOS) ve Modular Architecture SPM yazılarına bakabilirsin; ağ katmanını optimize etme pratikleri için Network Layer Optimizasyonu, uygulama açılış performansını mimariyle ilişkilendirmek için iOS Uygulama Açılış Optimizasyonu, bellek yönetimini state tasarımına bağlamak için ise iOS Bellek Yönetimi yazısı iyi birer devam noktası.
Kaynaklar
- Guide to app architecture — Android'in resmi mimari rehberi; SSOT, UDF ve katman tanımlarının birincil kaynağı.
- BackgroundTasks framework — Apple'ın arka plan görev framework'ü, genel bakış ve görev tipleri.
- BGTaskScheduler — görev kaydı ve gönderimi için birincil sınıf referansı.
- BGProcessingTaskRequest — requiresNetworkConnectivity ve requiresExternalPower alanlarının kaynağı.
- BGAppRefreshTask — app refresh görev sınıfı referansı.
- BGProcessingTask — processing görev sınıfı referansı.
- Android 15 davranış değişiklikleri — API 35 hedefleyen uygulamalarda foreground service çalışma süresi sınırları.
- Android 16 davranış değişiklikleri — API 36 hedefleyen ve Android 16+ cihazda çalışan uygulamalarda varsayılan predictive back sistem animasyonları.
- WorkManager: Getting started — offline arka plan işlerinin güncel birincil aracı.
- WorkManager releases — WorkManager 2.12.0 sürüm notları.
- Google Play hedef API şartları — Play Store hedef API zorunluluk takvimi.
- Apple Foundation Models — cihaz-üstü LLM'e Swift API erişimi.
