پاسخ کوتاه: انتشار خودکار محصول از اودو به اینستاگرام با یک دکمه انجام می‌شود ولی زیر آن یک معماری دو مرحله‌ای است: کانتینر رسانه (ساخت تصویر با کد یکتا) و صف انتشار با سهمیه‌ی روزانه و قفل تکرار — تا هیچ پستی دوبار نرود و هیچ ریکوئستی بلاک نشود. جزئیات مهندسی‌اش در همین مقاله.
چرا «صف» قلب این سیستم است؟
- سهمیه‌ی روزانه اینستاگرام واقعی است؛ انتشار پشت‌سرهم = اکشن بلاک
- قفل یکتا روی شناسه محصول: باگ یا تلاش مجدد، پست تکراری نمی‌سازد
- تلاش مجدد با فاصله نمایی: خطای موقت اینستاگرام ماجرای نصفه‌کاره نمی‌سازد
محصول نهایی: شاپ اینستاگرام ابرک.
Yanıt özeti: Otomatik gönderi yayınlama «tek bir HTTP isteği» değildir. Instagram'ın resmi API'si yayınlamayı iki aşamada gerçekleştirir (önce medya konteyneri oluşturma, ardından yayınlama); görsel Meta tarayıcısı tarafından alınabilmesi için herkese açık bir adreste bulunmalıdır; her hesabın günlük kotası vardır ve ağ da kesintiye uğrayabilir. Doğru mimari bu işlemi kullanıcı işleminden çıkarır ve benzersiz anahtarlı bir çıkış kuyruğuna bırakır.
Neden kullanıcı işleminde doğrudan yayın bir hatadır?
İlk cazip seçenek şudur: kullanıcı düğmeye basar, kod o anda isteği API'ye gönderir ve sonucu gösterir. Bu tasarımın üç öngörülebilir başarısızlığı vardır:
- Uzun Süreli Veritabanı Kilidi: İşlem, ağ gidiş-gelişi tamamlanana kadar açık kalır ve yük altında sistemin tamamını yavaşlatır.
- Belirsiz durum: İstek gönderildikten sonra ve yanıt alınmadan bağlantı kesilirse gönderinin yayınlanıp yayınlanmadığını bilemezsiniz. Yeniden deneme yinelenen gönderi oluşturabilir.
- Yanıltıcı işlem geri alımı (rollback): Odoo işlemi herhangi bir nedenle geri alınırsa gönderi kaydı silinir; ancak Instagram'a fiilen gönderilmiş içerik varlığını sürdürür.
Genel kural: Hiçbir ağ giriş/çıkışı kullanıcı işlemi içinde gerçekleştirilmemelidir. Kullanıcının işi yalnızca «niyet kaydı» olmalıdır; gerçek yürütme bir arka plan çalışanına aittir.
Yayın hattı: beş adım
- Hazırlık: Benzersiz kod atama, izin verilen oran ve boyutta görsel oluşturma ve şablondan altyazı oluşturma. Bu adımın çıktısı tamamen yereldir; hiçbir ağ bağlantısı gerektirmez.
- Kuyruğa alma: İçerik benzersiz anahtarıyla bir iş (job) kaydı oluşturulur. Aynı içerik tekrar kuyruğa alınırsa yeni bir kayıt değil, aynı kayıt döner.
- Medya Konteyneri Oluşturma: Arka plan işçisi, görselin genel adresini ve altyazı metnini
/mediauç noktasına gönderir ve bir konteyner kimliği alır. - Yayınlama: Konteyner kimliği
/media_publishuç noktasına gönderilir ve nihai medya kimliği döner; gönderiyi kalıcı olarak izlenebilir kılan da budur. Bu akışın ayrıntıları Meta içerik yayınlama belgeleri yer almaktadır. - Eşitleme: Gönderinin kalıcı bağlantısı okunur ve kayda kaydedilir; böylece yorumlar ve istatistikler daha sonra aynı gönderiye bağlanabilir.
Görsel sorunu: tarayıcının bunu alabilmesi gerekmektedir
Bu mimaride görseli yüklemezsiniz; bir adres verirsiniz ve platform görseli kendisi alır. Bu ciddi bir kısıtlamadır: adres herkese açık, kimlik doğrulaması gerektirmeyen ve Meta sunucularının erişebileceği bir adres olmalıdır. Bu aşamadaki en yaygın hatalar (medya alma hatası) neredeyse her zaman şunlardan birinden kaynaklanır: dahili adres veya zorunlu giriş arkasında olması, geçersiz TLS sertifikası, izinsiz format (görsel JPEG olmalı), üst sınırı aşan boyut veya izin verilen aralığın dışında en-boy oranı.
Sunucusu dışarıdan erişilemeyen kurulumlar için çözüm bir ara röledir: görsel röleye bir kez yüklenir, röle rastgele bir token ile genel ve geçici bir adres oluşturur ve yayınlandıktan sonra dosya zamanlanmış bir temizleyiciyle silinir. Yan faydası, ürün görselinizin tahmin edilebilir bir adreste sonsuza dek kalmamasıdır.
Kota: sorun, tahmin etmeyin
Her hesabın 24 saatlik sürede API aracılığıyla yayınlama için belirli bir sınırı vardır. Mesele şu ki bu sayıyı tahmin etmeyin: API'nin kendisinin tüketilen kotayı sorgulama noktası vardır ve doğru tasarım her yayınlamadan önce bunu sorgular. Kota dolmuşsa doğru davranış «hata vermek» değildir; doğru davranış gönderinin «kota bekleniyor» durumunda kalması ve pencere açıldıktan sonra otomatik olarak yayınlanmasıdır. Satıcı açısından bu iki davranış arasındaki fark, «sistem bozuldu» ile «sistem işini biliyor» arasındaki farktır.
Tekrara karşı güvenlik: benzersiz ve etkisiz anahtar (idempotency)
Her dağıtık sistemde "yeniden deneme" kaçınılmazdır; koruyucu olmadan yeniden deneme tekrarlanan gönderi anlamına gelir. Çözüm sunan kavram tekrarsallık (idempotency) ilkesidir — aynı ilke ki RFC 9110 HTTP yöntemleri için tanımlanmıştır: bir işlemin birden fazla kez çalıştırılması, tek seferlik çalıştırılmasıyla aynı etkiyi vermelidir.
Pratik uygulaması basittir: gönderinin gerçek içeriğinden (hesap, ürün, kod, görsel özeti ve açıklama) bir UUID sürüm 5 — yani şuna göre isme dayalı bir kimlik — RFC 9562 — oluşturulur ve kuyruk tablosuna benzersiz kısıtlama eklenir. Aynı içerik her zaman aynı anahtarı üretir; dolayısıyla ikinci kayıt hiç oluşmaz. Altyazı veya görsel değişirse anahtar değişir ve yeni yayın yapılabilir — tam olarak beklediğimiz davranış.
Hatalar: Hangileri yeniden denenmeli?
Tüm hatalar aynı değildir ve onlara aynı şekilde davranmak maliyetli olur. Pratik sınıflandırma:
| Kategori | Örnek | Doğru davranış |
|---|---|---|
| Geçici | Ağ kesintisi, hız sınırı, geçici medya getirme hatası | Üstel aralıklı yeniden deneme |
| Kota | 24 saatlik sınırın dolması | Pencere açılana kadar bekleme, başarısızlık olarak saymadan |
| Kalıcı | Geçersiz token, reddedilen erişim, izinsiz içerik | Derhal durdurma ve kullanıcıyı bilgilendirme; yeniden deneme yalnızca kaynak tüketir |
Biraz rastgele dağılım içeren üstel geri çekilme (exponential backoff), birinci kategori için standart kalıptır: her başarısızlık bekleme süresini birkaç katına çıkarır; böylece yük altındaki servis, eş zamanlı yeniden denemelerinin hücumuyla daha kötü bir duruma düşmez.
İki bağlantı yolu: doğrudan ve aktarmalı
API çağrıları üzerinde ince bir soyutlama katmanı — «doğrudan» ve «röleli» iki uygulama ile — tüm akış mantığının (kuyruk, kota, hatalar) bir kez yazılmasına ve bağlantı yolunun değiştirilmesinin yalnızca hesap formunda tek bir seçim olmasına olanak tanır. Röleli modda, her istek «zaman damgası, nonce, gövde» üçlüsü üzerinde HMAC ile imzalanır (RFC 2104) ve tek kullanımlık nonce, isteğin tekrar oynatılmasını (replay) önlemek için röle tarafında kaydedilir. Gelen olaylar da gövdelerinin tek bir baytı bile yorumlanmadan önce resmi Meta imzasıyla doğrulanır.
Neyi loglamalıyız (ve neyi asla)?
Hata ayıklama için şunların kaydı şarttır: çağrılan uç nokta, durum kodu, platform hata kimliği, süre, iş kimliği ve deneme sayısı. Ve istisnasız bir kural: erişim token'ı asla günlüğe yazılmamalı — ne tam hâliyle ne de kesilmiş olarak. Token hesap kaydında ve yalnızca sistem yöneticisi grubu için görünür, hata metinlerinde de kayıttan önce temizlenir.
Özet
Güvenilir bir yayın hattı dört parçadan oluşur: ağı kullanıcı işleminin dışına almak, idempotentlik için benzersiz anahtar, hataları doğru sınıflandırmak ve kota tahmin etmek yerine sormak. İşte bu dört parça, «zaman zaman çalışan bir betik» ile «işletmenin satışını emanet edebileceği bir özellik» arasındaki farkı yaratır. Odoo'daki nihai sonucu görmek için, Kurulum kılavuzu ve tamamlayıcı dönüşüm yolu için, Yorum'dan direkt mesaja makale inceleyin.
