--- title: "Senkron mu Asenkron mu? HTTP ve Kuyruk Arasındaki Sınır" description: "Bir işi HTTP isteğiyle anında mı yapmalı, kuyruğa mı atmalı? Yanıt süresi ve hata toleransı üzerinden karar çizgisi." url: https://sade.dev/tr/notes/senkron-mu-asenkron-mu/ lang: tr author: "Muhammet Şafak" published: 2026-06-27 updated: 2026-09-06 section: Note tags: ["architecture","queue","async","api"] summary: "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." --- # Senkron mu Asenkron mu? HTTP ve Kuyruk Arasındaki Sınır > 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/notes/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. ## 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. ## 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. ## 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