# Senkron mu Asenkron mu? HTTP ve Kuyruk Arasında Karar > Bir işi HTTP isteğiyle anında mı yapmalı, kuyruğa mı atmalı? Yanıt süresi ve hata toleransı üzerinden karar çizgisi. - Tür: Notlar - Yayın: 2026-06-27 - Güncelleme: 2026-09-30 - Etiketler: architecture, queue, async, api - Okuma süresi: 2 dk okuma - Kaynak: https://muhammetsafak.com/tr/muhendislik/notlar/senkron-mu-asenkron-mu/ - Dil: tr-TR - Yazar: Muhammet Şafak --- > **Kısaca:** Senkron mu asenkron mu, bir performans sorusu değil, kim bekliyor sorusudur. Kullanıcı sonucu görmek zorundaysa iş istek içinde kalır; değilse kuyruğa gider ve istek 202 Accepted döner. Aynı çizgiyi hata keskinleştirir: senkron hata bir hata ekranıdır, asenkron hata bir retry'dır — kararsız bir üçüncü partinin senkron yolda durmamasının sebebi tam olarak budur. Bir kayıt formu sekiz saniye sürüyordu. İstek içinde sırayla şunlar oluyordu: kullanıcı kaydediliyor, hoş geldin e-postası gönderiliyor, bir PDF üretiliyor, bir CRM'e kayıt işleniyor. Kullanıcı bu sekiz saniye boyunca dönen bir spinner'a bakıyordu — oysa onu ilgilendiren tek şey, kaydının oluşup oluşmadığıydı. Bir işi HTTP isteği içinde anında mı yapmalı, kuyruğa mı atmalı? Çizgi göründüğünden net. ## Karar çizgisi: kullanıcı sonucu bekliyor mu? Tek bir soru kararın çoğunu verir: **kullanıcı bu işin sonucunu görmek zorunda mı?** - Cevap "evet" ise iş senkron kalır — istek içinde, yanıt dönmeden biter. - Cevap "hayır" ise iş kuyruğa gider — istek "kabul edildi" der ve döner. Yukarıdaki formda kullanıcı sadece "kaydım oluştu mu" cevabını bekliyor. E-posta, PDF, CRM — hiçbirinin sonucunu o ekranda görmesi gerekmiyor. Üçü de yanlış tarafta duruyordu. ## Hangi işler senkron kalmalı? Kullanıcının sonucunu doğrudan gördüğü işler istek içinde kalır: - Girdi doğrulama — hata anında dönmeli. - Asıl kaynağın yaratılması — kullanıcı oluşturma, sipariş oluşturma. - Ödeme **yetkilendirmesinin sonucu** — kart geçti mi geçmedi mi, kullanıcı bunu o an bilmeli. - Kullanıcının bir sonraki adımda göreceği veri. Bunları kuyruğa atmak, kullanıcıya "sonra bak" demektir — ve çoğu zaman kötü bir deneyimdir. ## Hangi işler kuyruğa gitmeli? Kullanıcının sonucunu o an görmesi gerekmeyen her iş asenkrondur: - E-posta ve bildirim. - PDF ve rapor üretimi. - Webhook gönderimi. - Üçüncü parti senkronizasyonu — CRM, analitik, arama indeksi. - Görsel işleme, dışa aktarma. Bunlar için doğru yanıt `202 Accepted`'dir: "isteğini aldım, işliyorum." Kullanıcı beklemez, sistem işi kendi temposunda yapar. ## Çizgiyi yanıt süresi keskinleştirir Her endpoint için bir p95 bütçeniz olmalı — diyelim 300 ms. Bir adım bu bütçeyi tek başına yiyorsa ve kullanıcı o adımın sonucunu görmek zorunda değilse, o adım kuyruğa gider. Senkron zincir, en yavaş halkası kadar hızlıdır. PDF üretimi 4 saniye sürüyorsa, kullanıcı oluşturma da 4 saniye sürer — PDF'in yanıtla hiçbir ilgisi olmasa bile. ## Hata toleransı: asıl ayrım Asıl mesele hız değil, hatadır. Senkron ve asenkron, başarısızlığı bambaşka karşılar: - **Senkron hata** = kullanıcı bir hata ekranı görür. İş kaybolur. - **Asenkron hata** = job retry edilir, gerekirse DLQ'ya düşer, [kuyruk](/tr/muhendislik/notlar/laravel-queue-production-yavaslama/) sonra işler. Buradan tek bir kural çıkar: **kararsız bir üçüncü parti asla senkron yolda durmamalı.** O CRM çağrısı istek içindeyse, CRM her çöktüğünde sizin kayıt formunuz da çöker. Kuyruğa alınmış bir çağrı ise, CRM döndüğünde retry kendiliğinden tamamlanır. Üçüncü partinin uptime'ı sizin uptime'ınız olmaktan çıkar. ## 202 ve durum sorgusu kalıbı İş kuyruğa gidince kullanıcıya bir takip yolu bırakın: ``` POST /exports → 202 Accepted { "id": "exp_1a2b", "status": "processing" } GET /exports/exp_1a2b → 200 OK { "status": "done", "url": "..." } ``` Kullanıcı sonucu beklemiyordur ama bazen merak eder. Bir durum endpoint'i ya da hazır olunca gönderilen bir bildirim, bu boşluğu kapatır. > **Tan:** İşi kuyruğa attığınızda hatayı kullanıcının ekranından alıp kimsenin bakmadığı bir yere taşımış olabilirsiniz. Kuyruğa giden her iş için, düşerse kimin göreceği ve kimin yeniden deneyeceği baştan belli olmalı. Bu sorunun cevabı yoksa, senkron yolun hatası en azından görünür bir yerde çıkar. ## Sınır nerede kalkar? Bazı işler ikisinin arasındadır: kullanıcı sonucu görmek ister ama iş de yavaştır. Burada üçüncü bir yol var — işi senkron başlatın, ilk anlamlı sonucu hemen döndürün, gerisini kuyruğa devredin. Sipariş kaydını anında oluşturun (senkron), faturayı arkada üretin (asenkron). Çizgiyi her iş için ayrı çizin; "her şey kuyruğa" da "her şey senkron" kadar yanlıştır. --- Senkron mu asenkron mu sorusu bir performans sorusu değil, bir "kim bekliyor" sorusudur. Kullanıcının beklemediği hiçbir iş, onun isteğini bekletmemeli. İsteği yalnızca, cevabını gerçekten istediği işle meşgul edin. ## Kaynaklar - [RFC 9110, 15.3.3: 202 Accepted](https://www.rfc-editor.org/rfc/rfc9110.html#name-202-accepted) — IETF - [Release It! Second Edition: stability patterns and antipatterns](https://pragprog.com/titles/mnee2/release-it-second-edition/) — Michael T. Nygard, Pragmatic Bookshelf - [Using dead-letter queues in Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) — AWS ## Sık sorulanlar ### Hangi işler HTTP isteğinin içinde kalmalı? Kullanıcının sonucunu doğrudan gördüğü işler: girdi doğrulama, asıl kaynağın yaratılması, ödeme yetkilendirmesinin sonucu ve kullanıcının bir sonraki adımda göreceği veri. Bunları kuyruğa atmak, kullanıcıya sonra bak demektir ve çoğu zaman kötü bir deneyimdir. ### Kararsız bir üçüncü parti neden senkron yolda durmamalı? Çünkü onun kesintisi sizin kesintiniz olur. İstek içindeki bir CRM çağrısı, CRM her çöktüğünde kayıt formunu da düşürür. Kuyruğa alınmış aynı çağrı ise retry edilir ve CRM döndüğünde kendiliğinden tamamlanır; üçüncü partinin uptime'ı sizin uptime'ınız olmaktan çıkar.