Sorun: ekstra altyapı olmadan zamanlanmış işler\n\nÇoğu uygulamanın daha sonra yapılması ya da belirli aralıklarla çalışması gereken işler olur: takip e-postaları göndermek, gece faturalama kontrolü yapmak, eski kayıtları temizlemek, bir raporu yeniden oluşturmak veya önbelleği yenilemek.\n\nErken aşamada, arka plan işleri için tam bir kuyruk sistemi eklemek cazip gelebilir çünkü "doğru" yol gibi görünür. Ama kuyruklar ekstra parça getirir: çalıştırılacak, izlenecek, dağıtılacak ve hata ayıklanacak başka bir servis. Küçük bir ekip (ya da tek kurucu) için bu ekstra yük işi yavaşlatabilir.\n\nGerçek soru şu: daha fazla altyapı kurmadan zamanlanmış işleri güvenilir şekilde nasıl çalıştırırsınız?\n\nİlk denemeler genellikle basittir: bir cron girdisi bir uç noktayı tetikler ve o uç nokta işi yapar. Bu işe yarar, ta ki yaramaz hale gelene kadar. Birden fazla sunucunuz olduğunda, yanlış zamanda yapılan bir deploy veya beklenenden uzun süren bir iş olduğunda kafa karıştırıcı hatalar görmeye başlarsınız.\n\nZamanlanmış işler genellikle birkaç öngörülebilir şekilde bozulur:\n\n- Çift çalıştırma: iki sunucu aynı görevi çalıştırır; faturalar iki kez oluşturulur ya da e-postalar çift gönderilir.\n- Kayıp çalıştırmalar: deploy sırasında cron çağrısı başarısız olur ve kimse fark etmez.\n- Sessiz hatalar: iş bir kere hata verir ve tekrar çalışmaz çünkü yeniden deneme planı yoktur.\n- Kısmi işler: iş yarıda çöker ve veriler garip bir durumda kalır.\n- Denetim izi yok: "en son ne zaman çalıştı?" veya "dün gece ne oldu?" gibi soruları cevaplayamazsınız.\n\nCron + veritabanı deseni orta bir yol sunar. Hala cron'u bir zamanlayıcı olarak kullanırsınız, ancak iş niyeti ve iş durumu veritabanında saklanır, böylece sistem koordinasyon, yeniden deneme ve ne olduğunun kaydını tutabilir.\n\nBu, zaten bir veritabanınız (çoğu zaman PostgreSQL), az sayıda iş türü ve minimum işletme işiyle öngörülebilir davranış istediğinizde iyi bir uyum sağlar. Ayrıca modern yığınlarda (örneğin React + Go + PostgreSQL) hızla kurulan uygulamalar için doğal bir tercihtir.\n\nÇok yüksek throughput, ilerleme akışı gerektiren uzun süreli işler, birçok iş türü arasında sıkı sıralama veya yoğun fan-out (dakikada binlerce alt görev) gerektiğinde uygun değildir. Bu durumlarda gerçek bir kuyruğa ve adanmış worker'lara yatırım genellikle kendini öder.\n\n## Temel fikir, sadece\n\nCron + veritabanı deseni, tam bir kuyruk sistemi çalıştırmadan zamanlanmış arka plan işlerini yürütür. Hala cron (veya başka bir zamanlayıcı) kullanırsınız, ama cron neyi çalıştıracağını belirlemez. Sadece sık sık (dakikada bir yaygın) bir worker'ı uyandırır. Veritabanı hangi işin vaktinin geldiğini belirler ve her işin sadece bir worker tarafından alınmasını sağlar.\n\nBunu ortak bir beyaz tahtadaki paylaşılan bir kontrol listesi gibi düşünün. Cron her dakika odaya girip "Yapacak bir şeyi olan var mı?" diye soran kişi. Veritabanı ise neyin vaktinin geldiğini, hangisinin alındığını ve hangisinin yapıldığını gösteren beyaz tahta.\n\nParçalar basittir:\n\n- Tek bir zamanlayıcı tetikleyici sık çalışır.\n- Bir jobs tablosu "ne" ve "ne zaman"ı (çalışma zamanı), durum ve deneme sayısını tutar.\n- Bir veya daha fazla worker tabloyu tarar, bir işi talep eder ve işi yapar.\n- Talep etme, iki worker'ın aynı satırı kaptığı durumu önlemek için veritabanı kilidi ile yapılır.\n- Veritabanı, neyin çalıştığının, neyin başarısız olduğunun ve neyin yeniden deneneceğinin tek kaynağı olur.\n\nÖrnek: her sabah fatura hatırlatmaları göndermek, önbelleği her 10 dakikada bir yenilemek ve gece eski oturumları temizlemek istiyorsunuz. Üç ayrı cron komutu yerine (her birinin kendi çakışma ve hata modlarıyla), iş girdilerini tek bir yerde saklarsınız. Cron aynı worker sürecini başlatır. Worker Postgres'e "Şu anda ne vaktinde?" diye sorar ve Postgres çalışanın güvenli şekilde tam olarak bir işi almasına izin verir.\n\nBu yöntem kademeli olarak ölçeklenir. Bir sunucuda bir worker ile başlayabilirsiniz. Daha sonra birden fazla sunucuda beş worker çalıştırabilirsiniz. Anlaşma aynıdır: tablo sözleşmedir.\n\nZihniyet değişikliği basittir: cron sadece uyandırma çağrısıdır. Veritabanı trafiği yöneten görevli gibidir — ne çalıştırılabileceğine karar verir, ne olduğunu kaydeder ve bir şey ters gittiğinde size net bir geçmiş verir.\n\n## jobs tablosunu tasarlamak (pratik bir şema)\n\nBu desen en iyi, veritabanınızın neyin çalışması gerektiğinin, ne zaman çalışacağını ve son seferde ne olduğunu kaydettiği durumda işler. Şema süslü değildir, ama küçük detaylar (kilit alanları ve doğru indeksler) yük arttıkça büyük fark yaratır.\n\n### Tek tablo mu, iki tablo mu?\n\nİki yaygın yaklaşım:\n\n- : sadece her işin en son durumunu önemsiyorsanız (basit, az join).\n- : "bu iş nedir" ile "her çalıştığında ne oldu" arasında net ayrım isterseniz (daha iyi geçmiş, hata ayıklama kolaylığı).\n\nHataları sık sık debug etmeniz beklentisi varsa geçmiş tutun. En küçük kurulumu istiyorsanız tek tabloyla başlayıp sonra geçmiş ekleyin.\n\n### Pratik bir şema (iki tablo versiyonu)\n\nAşağıda PostgreSQL dostu bir düzen var. Go ile PostgreSQL inşa ediyorsanız bu sütunlar struct'lara temizce eşleşir.\n\n\n\nBirkaç detay ileride sizi kurtarır:\n\n- kısa bir string olsun (örneğin ) ve ona göre yönlendirme yapın.\n- 'ı olarak saklayın, böylece migration yapmadan evriltebilirsiniz.\n- sizin "bir sonraki vade zamanı"nızdır. Cron (veya zamanlayıcı betik) bunu ayarlar, worker'lar tüketir.\n- ve worker'ların işleri birbirinin üstüne binmeden talep etmesine izin verir.\n- kısa ve insanın okuyabileceği bir mesaj olsun. Stack trace'leri ihtiyaç varsa başka yerde tutun.\n\n### İhtiyacınız olacak indeksler\n\nİndeks yoksa worker'lar çok fazla tarama yapmak zorunda kalır. Şunlarla başlayın:\n\n- Vakit gelmiş işleri hızlı bulmak için bir indeks: \n- Süresi dolmuş kilitleri tespit etmeye yardımcı indeks: \n- Opsiyonel: sadece aktif işler için kısmi indeks (örneğin ve içinde)\n\nBunlar, tablo büyüdüğünde bile "sonraki çalıştırılabilir işi bul" sorgusunu hızlı tutar.\n\n## İşleri güvenli şekilde kilitleme ve alma\n\nAmaç basit: birçok worker çalışabilir, ama sadece biri belirli bir işi almalı. Eğer iki worker aynı satırı işliyorsa çift e-postalar, çift ücretleme veya karmaşık verilerle karşılaşırsınız.\n\nGüvenli bir yaklaşım, iş talebini bir "kira (lease)" gibi görmektir. Worker işi kısa bir süreliğine kilitler. Worker çökerse kira süresi biter ve başka bir worker işi alabilir. bunun için vardır.\n\n### Çöküşler işin sonsuza dek bloklanmaması için kiralamayı kullanın\n\nKiralamadan yoksun olunca, worker işi kilitlediği halde asla açamayabilir (proses öldü, sunucu yeniden başlatıldı, deploy hatalı). sayesinde zaman geçince iş tekrar alınabilir.\n\nTipik kural: bir iş ise ya da ise alınabilir.\n\n### İşleri tek atomik güncellemede talep edin\n\nÖnemli detay, işi tek bir ifadeyle (veya tek transaction içinde) talep etmektir. Veritabanının hakem olmasını istersiniz.\n\nAşağıda PostgreSQL için yaygın bir desen: bir vadesi gelmiş işi seç, kilitle ve worker'a döndür. (Bu örnek tek tablosu kullanıyor; aynı fikir için de geçerli.)\n\n\n\nNeden işe yarıyor:\n\n- birden fazla worker'ın yarışmasını sağlar ama birbirlerini bloklamazlar.\n- Kira talep anında ayarlanır, böylece diğer worker'lar süresi dolana kadar işi görmezden gelir.\n- yarışı kazanan worker'a satırı verir.\n\n### Kira süresi ne kadar olmalı ve nasıl yenilenir?\n\nKirayı normal çalışma süresinden uzun, ama bir çöküşün hızlı toparlanacağı kadar kısa tutun. Çoğu iş 10 saniyede bitiyorsa 2 dakikalık kira yeterlidir.\n\nUzun işler için çalışırken kirayı yenileyin (heartbeat). Basit bir yaklaşım: her 30 saniyede bir 'ı uzatın eğer hala işin sahibiyse.\n\n- Kira süresi: tipik iş zamanınızın 5x ila 20x'i\n- Heartbeat aralığı: kiranın 1/4 ila 1/2'si\n- Yenileme güncellemesi içermeli\n\nSon koşul önemlidir. Bir worker artık sahibi olmadığı bir işin kirasını uzatmasını engeller.\n\n## Öngörülebilir davranan yeniden denemeler ve geri çekilme\n\nYeniden denemeler, bu desenin ya sakin hissettirdiği ya da gürültülü bir karmaşaya dönüştüğü yerdir. Amaç basit: bir iş başarısız olduğunda, daha sonra tekrar deneyin; bunu açıklayabilir, ölçebilir ve durdurabilirsiniz.\n\nİlk olarak iş durumunu açık ve sonlu yapın: , , , , . Çoğu takım pratikte i "başarısız oldu ama yeniden denenecek" anlamında kullanır; ise "başarısız oldu ve vazgeçildi" demektir. Bu ayrım sonsuz döngüleri önler.\n\nDeneme sayacı ikinci koruma katmanıdır. (kaç kere denendi) ve (kaç kere izin verildi) saklayın. Bir worker hata yakaladığında şu adımları izlemeli:\n\n- 'ı artır\n- ise , değilse durumunu ata\n- Sonraki deneme için hesapla (sadece için)\n\nGeri çekilme (backoff), bir sonraki 'i belirleyen kuraldır. Birini seçin, belgelendirin ve tutarlı kalın:\n\n- Sabit gecikme: hep 1 dakika bekle\n- Üssel: 1dk, 2dk, 4dk, 8dk\n- Üssel ve üst sınır: üssel ama örneğin en fazla 30dk\n- Jitter ekle: işler aynı saniyede yeniden denememesin diye biraz rastgelelik katın\n\nJitter, bir bağımlılık çöktüğünde ve döndüğünde önem taşır. Yoksa yüzlerce iş aynı anda yeniden dener ve tekrar başarısız olur.\n\nHataları görünür ve hata ayıklamaya uygun tutacak kadar bilgi saklayın. Tam bir log sistemi gerekmez ama temel bilgiler olmalı:\n\n- (kısa mesaj, admin ekranında güvenle gösterilebilir)\n- veya (benzer hataları gruplayabilmek için)\n- ve \n- opsiyonel (boyutu kontrol ediliyorsa)\n\nİyi çalışan somut bir kural: işleri 10 denemeden sonra yapın ve üssel geri çekilme ile jitter uygulayın. Bu, geçici hataların tekrar denenmesini sağlar ama bozuk işleri sonsuza kadar CPU yakmaya bırakmaz.\n\n## İdempotans: bir iş tekrar çalışsa bile tekrarı önlemek\n\nİdempotans, işiniz iki kez çalıştırılsa bile aynı sonucun üretilmesini sağlar. Bu desen için önemlidir çünkü aynı satır çöküş, zaman aşımı veya yeniden deneme nedeniyle tekrar seçilebilir. "Fatura e-postası gönder" gibi bir iş iki kez çalıştırılmak istenmeyen sonuçlar doğurur.\n\nPratik düşünce: her işi (1) işi yapmak ve (2) etkiyi uygulamak olarak ayırın. Etkinin bir kere olmasını istersiniz, iş kaç kez denenirse denensin.\n\n### İşle ilgili idempotans anahtarı kullanın\n\nIdempotans anahtarı işin temsil ettiği gerçek işten gelmeli, worker denemesinden değil. İyi anahtarlar kararlı ve anlaşılırdır: , veya . İki deneme aynı gerçek dünya olayı içinse aynı anahtarı paylaşmalıdır.\n\nÖrnek: "2026-01-14 için günlük satış raporu oluştur" anahtarı olabilir. "812 numaralı faturayı tahsil et" için .\n\n### "Sadece bir kere" kuralını veritabanı kısıtlarıyla sağlayın\n\nEn basit koruma, PostgreSQL'in tekrarları reddetmesine izin vermektir. Idempotency anahtarını indekslenebilir bir yere koyun ve benzersiz kısıtlama ekleyin.\n\n\n\nBu, aynı anahtara sahip iki satırın aynı anda var olmasını engeller. Tasarımınız birden fazla satıra izin veriyorsa (geçmiş için), benzersizliği bir "etki" tablosunda tutun; örneğin veya .\n\nKorunması gereken yaygın yan etkiler:\n\n- E-postalar: göndermeden önce tablosuna benzersiz anahtarla bir satır oluşturun veya gönderildikten sonra sağlayıcı mesaj kimliğini kaydedin.\n- Webhook'lar: kaydı tutun ve varsa atlayın.\n- Ödemeler: ödeme sağlayıcılarının idempotency özelliğini kullanın ve kendi veritabanı benzersiz anahtarınızı ekleyin.\n- Dosya yazma: geçici bir isimle yazıp sonra yeniden adlandırın veya ile anahtelenmiş kaydı tutun.\n\nPostgres destekli bir yığında (örneğin Go + PostgreSQL) bu benzersizlik kontrolleri hızlıdır ve veriye yakın tutulması kolaydır. Özet: yeniden denemeler normaldir, kopyalar istenmeyen.\n\n## Adım adım: minimal bir worker ve zamanlayıcı kurun\n\nSıkıcı ama güvenilir bir çalışma zamanı seçin ve ona bağlı kalın. Cron + veritabanı deseninin amacı daha az hareketli parça olduğundan, PostgreSQL ile konuşan küçük bir Go, Node veya Python süreci genellikle yeterlidir.\n\n### Beş küçük adımda inşa edin\n\n1) Bir tablosu (ve sonra kullanmak isteyebileceğiniz lookup tabloları) ekleyin, 'i indeksleyin ve işçi için uygun bir hızlandırıcı indeks (örneğin ) ekleyin.\n\n2) Uygulamanız 'i "now" veya geleceğe ayarlanmış bir zaman olarak eklemeli. Payload'ı küçük ve öngörülebilir tutun (ID'ler ve iş tipi, büyük blob'lar değil).\n\n\n\n3) Bunu bir transaction içinde çalıştırın. Birkaç vadesi gelmiş işi seçin, diğer worker'ların atlaması için kilitleyin ve aynı transaction içinde olarak işaretleyin.\n\n\n\n4) Her talep edilmiş iş için işi yapın, sonra durumuna ile güncelleyin. Eğer hata olursa, hata mesajını kaydedin ve geri çekilme ile durumuna geri koyun. Sonlandırma güncellemeleri küçük tutun ve proses kapanırken bile mutlaka çalıştırın.\n\n5) Basit bir formül kullanın: , ve sonrası yapın.\n\n### Basit görünürlük ekleyin\n\nİlk günden tam bir gösterge panosuna ihtiyacınız yok, ama problemleri fark edecek kadar bilgi olmalı.\n\n- Her iş için bir satır loglayın: alındı, başarılı, hatalı, yeniden denendi, öldü.\n- "Dead jobs" ve "uzun süredir running duran işler" için basit bir admin sorgusu veya görünüm oluşturun.\n- Sayılara göre (örneğin son bir saatte N'den fazla dead job) alarm kurun.\n\nGo + PostgreSQL yığını kullanıyorsanız, bu tek bir worker binary'sine ve cron tetikli bir plana temizce uyacaktır.\n\n## Kopyalayıp yapıştırabileceğiniz gerçekçi örnek\n\nKüçük bir SaaS uygulamasını hayal edin; iki zamanlanmış işi var:\n\n- Geceleyin süresi dolmuş oturumları ve eski geçici dosyaları kaldıran temizlik işlevi.\n- Her Pazartesi sabahı her kullanıcıya haftalık "aktivite raporu" e-postası gönderen iş.\n\nBasit tutun: işleri tutan bir PostgreSQL tablosu ve her dakika çalışan (cron tarafından tetiklenen) bir worker. Worker vadesi gelmiş işleri alır, çalıştırır ve başarı veya hatayı kaydeder.\n\n### Ne zaman iş kuyruğa alınır\n\nİşleri birkaç yerden kuyruğa alabilirsiniz:\n\n- Her gün 02:00'de: o gün için bir işi kuyruğa alınır.\n- Kayıt sırasında: kullanıcının bir sonraki Pazartesi'si için kuyruğa alınır.\n- Bir olaydan sonra (örneğin "kullanıcı Export rapora tıkladı"): belirli bir tarih aralığı için hemen çalışacak bir kuyruğa alınır.\n\nPayload, worker'ın ihtiyaç duyduğu minimum bilgiden oluşsun. Tekrar denemesi kolay olsun diye küçük tutun.\n\n\n\n### İdempotans çift gönderimi nasıl önler\n\nWorker en kötü anda çökebilir: e-postayı gönderdikten hemen sonra fakat işi "done" olarak işaretlemeden önce. Yeniden başladığında aynı işi tekrar alabilir.\n\nÇift gönderimi önlemek için çalışmanın doğal bir dedupe anahtarı olsun ve veritabanının bunu zorlayabileceği bir yerde saklayın. Haftalık raporlar için iyi bir anahtar olur. Göndermeden önce worker "Ben rapor X'i göndereceğim" kaydını tutar. Eğer o kayıt zaten varsa gönderimi atlar.\n\nBu basitçe üzerinde benzersiz bir kısıtlama ile tablosu veya iş üzerinde benzersiz olarak uygulanabilir.\n\n### Bir hata nasıl görünür (ve nasıl toparlanır)\n\nDiyelim e-posta sağlayıcınız zaman aşımına uğradı. İş hata verir, bu durumda worker:\n\n- 'ı artırır\n- hata mesajını debug için kaydeder\n- geri çekilme ile bir sonraki deneme zamanını ayarlar (örneğin: +1 dk, +5 dk, +30 dk, +2 saat)\n\nEğer belirlediğiniz limitin (örneğin 10 deneme) ötesinde hata verirse, işi "dead" yapın ve yeniden denemeyi durdurun. İş ya bir kere başarılı olur ya da açık bir takvime göre yeniden denenir; idempotans sayesinde yeniden denemeler güvenlidir.\n\n## Yaygın hatalar ve tuzaklar\n\nCron + veritabanı deseni basittir, ama küçük hatalar onu çoğaltmalar, takılı işler veya beklenmedik yük haline getirebilir. Çoğu sorun ilk çöküş, deploy veya trafik sıçramasından sonra ortaya çıkar.\n\n### Çift veya takılı işlere neden olan hatalar\n\nGerçek dünya olaylarının çoğu birkaç tuzaktan kaynaklanır:\n\n- Aynı işi birden fazla cron girdisiyle çalıştırmak ve lease kullanmamak. Eğer iki sunucu aynı dakikada tetiklenirse, talep etme adımı atomik değilse ikisi de aynı işi alabilir.\n- 'u atlamak. Bir worker işi aldıktan sonra çökerse, o satır "in progress" olarak kalabilir. Kira zaman damgası başka bir worker'ın daha sonra güvenli şekilde almasını sağlar.\n- Başarısızlıklarda anında yeniden deneme. Bir API çöktüğünde anında yeniden denemeler spike yaratır, rate limit'leri tüketir ve sürekli başarısız olur. Sonraki denemeyi geleceğe planlayın.\n\n- "en az bir kere"yi "tam olarak bir kere" gibi düşünmek. Bir iş iki kere çalışabilir (zaman aşımı, worker yeniden başlatma, ağ sorunları). İki kere çalıştırma zararlıysa yan etkileri tekrara dayanıklı hale getirin.\n\n- İş satırına çok büyük payload'lar koymak. Büyük JSON blob'ları tabloyu şişirir, indeksleri yavaşlatır ve kilitlemeyi ağırlaştırır. Bunun yerine bir referans (ör. , veya bir dosya anahtarı) saklayın ve çalışırken geri alın.\n\nÖrnek: haftalık bir fatura e-postası gönderiyorsunuz. Worker e-postayı gönderdikten sonra zaman aşımına uğrarsa ve işi done olarak işaretlemeden önce kapanırsa aynı iş yeniden denenebilir ve çift e-posta gönderilebilir. Bu desen normaldir; koruma için benzersiz "email sent" olayını fatura id'sine göre kaydedin.\n\n### Daha az belirgin tuzaklar\n\nZamanlama ve yürütmeyi aynı uzun transaction içinde karıştırmaktan kaçının. Ağ çağrılarını yaparken transaction açık tutarsanız, kilitleri gereğinden uzun süre elinizde tutar ve diğer worker'ları engellersiniz.\n\nMakinalar arasındaki saat farklarına dikkat edin. ve için uygulama sunucusu saatini değil veritabanı saatini ( PostgreSQL) kaynağınız yapın.\n\nNet bir maksimum çalışma süresi belirleyin. Eğer bir iş 30 dakika alabiliyorsa, kira süresini normalden uzun yapın ve gerekirse yenileyin. Aksi halde başka bir worker işi çalıştırma ortasında alabilir.\n\nİş tablonuzun sağlıklı kalmasını sağlayın. Tamamlanmış işler sonsuza kadar birikirse sorgular yavaşlar ve kilit rekabeti artar. Tablo çok büyümeden önce basit bir saklama (retention) kuralı belirleyin (arşivle veya sil).\n\n## Hızlı kontrol listesi ve sonraki adımlar\n\n### Hızlı kontrol listesi\n\nBu deseni hayata geçirmeden önce temel noktaları kontrol edin. Küçük bir eksiklik genellikle takılı işler, beklenmedik kopyalar veya veritabanını döven bir worker ile sonuçlanır.\n\n- Jobs tablonuzda temel alanlar var mı: , , , , (ve ne olduğunu görebilmek için gibi bir alan).\n- Her iş iki kere çalışsa bile zarar vermeyecek şekilde güvenli mi? Emin değilseniz idempotency anahtarı veya yan etki etrafında benzersiz kural ekleyin (ör. bir invoice için sadece bir fatura).\n- Hataları gözlemleyip ne yapılacağını belirleyeceğiniz net bir yer var mı: failed işleri görme, bir işi tekrar çalıştırma veya durdurma (dead) yetkisi.\n- Kira (lock) zaman aşımı iş için makul mu? Normal çalışmalara yeterince uzun, ama çöken worker'ların saatlerce ilerlemeyi durdurmayacağı kadar kısa olsun.\n- Yeniden deneme geri çekilmesi öngörülebilir mi? Tekrarlayan hataları yavaşlatmalı ve sonrası durdurmalı.\n\nBu noktalar doğruysa, cron + veritabanı deseni genellikle gerçek iş yükleri için yeterince stabil olur.\n\n### Sonraki adımlar\n\nKontrol listesi tamamlandıktan sonra günlük işletmeye odaklanın.\n\n- İki küçük admin işlemi ekleyin: "şimdi yeniden dene" ( ve kilidi temizle) ve "iptal" (işi terminal duruma taşı). Bu, olaylarda zaman kazandırır.\n- Worker her iş için bir satır loglasın: iş türü, iş id, deneme numarası ve sonuç. Artan hata sayıları için alarm ekleyin.\n- Gerçekçi bir spike ile yük testi yapın: aynı dakikada planlanmış çok sayıda iş. Talep etme yavaşlarsa doğru indeksi ekleyin (çoğunlukla ).\n\nBu deseni hızlıca kurmak isterseniz, Koder.ai (koder.ai) şema'dan dağıtıma kadar Go + PostgreSQL uygulaması oluşturmanıza yardımcı olabilir; siz kilit, yeniden deneme ve idempotans kurallarına odaklanırsınız.\n\nEğer daha sonra bu yapı yetersiz kalırsa, iş yaşam döngüsünü öğrenmiş olursunuz ve aynı fikirler tam bir kuyruk sistemine de iyi şekilde geçiş yapar.\n
