Geçen yıl, Mart 2025’te İstanbul’da bir ajans toplantısındaydım ve çok tanıdık bir sahne gördüm. Beş kişi. Sabah 09.00. Hepsi aynı rakip hesapları tek tek açıyor, Instagram ve TikTok’ta “yeni bir şey var mı” diye kaydırıp duruyordu (kendi tecrübem). Hani küçük gibi görünür bu iş, değil mi? Değil. Toplamda haftada saatler gidiyor —. Açık konuşayım, o dakikalar sadece zamanı değil, insanın zihinsel enerjisini de yiyor çünkü her kontrol “belki bu sefer bir şey vardır” umuduyla yapılıyor ama çoğunlukla boş çıkıyor.
İşin aslı şu ki bu tarz takip işleri çoğu ekipte sessizce büyüyor. Kimse “ben bugün rakibi kontrol ettim” diye övünmüyor ama herkes yapıyor. Sonra biri çıkıp bunu otomatiğe bağlayınca ortam bir anda değişiyor. Daha az boş uğraş. Daha hızlı tepki. Daha temiz akış.
Ve işler burada ilginçleşiyor.
Neden böyle bir bot lazım oldu?
Rakip takibi deyince çoğu kişinin aklına devasa analiz panelleri geliyor. Halbuki bazen mesele çok basit: rakip yeni içerik paylaştı mı, paylaştıysa ne zaman, bizim ekibe haber düşsün mü? Bu kadar.
Ben buna ilk kez 2024 sonbaharında Kadıköy’de bir coworking alanında takılırken kafa yordum. Bir arkadaşımın ekibinde manuel kontrol yüzünden kampanya kaçmıştı; “sabah bakarız” denmiş, öğlene kalmadan rakip duyuruyu patlatmıştı bile. O gün anladım ki bu iş için süslü AI modellerine falan gerek yok. Doğru kurulmuş sade bir bot fazlasıyla yeterli.
Burada anlatılan yapı da tam olarak bunu yapıyor: belirlediğin hesapları düzenli aralıklarla kontrol ediyor, yeni gönderi varsa fark ediyor ve Discord’a kısa ama zengin bir uyarı bırakıyor. Ne abartılı ne gösterişli… sadece işini görüyor.
Rakip paylaşımı geldiği an haber almak bazen “güzel özellik” değil, doğrudan para kazandıran avantaj oluyor. En çok da pazarlama ve sosyal medya ekiplerinde bu fark bayağı hissediliyor.
Mantık basit: izle, karşılaştır, bildir
Bu çözümün güzelliği şu: karmaşık davranmıyor. Bot belli aralıklarla platformdan veri çekiyor, elindeki son kayıtla kıyaslıyor ve yeni içerik bulursa Discord’a atıyor. Üç adım var; izleme, diff alma ve bildirim gönderme. Neden önemli bu? Hepsi bu.
Şunu fark ettim: Benzer yapıyı kendi küçük yan projemde geçen yaz İzmir’de test etmiştim — orada amaç e-ticaret rakibini izlemekti. Mantık aynıydı. En iyi tarafı şu oldu: veriyi düzgün saklayınca aynı post için iki kere alarm çalmıyor. İnsanlar genelde tam burayı atlıyor ve sonra kanal bildirim çöplüğüne dönüyor. Tatsız.
Peki neden?
No fancy ML here — gerçekten de gerek yoktu zaten. Problem tahmin etmek değil; mevcut içeriği güvenilir şekilde yakalamak ve tekrar etmeyen sağlam bir sistem kurmak. Daha fazla bilgi için Tamir Edilmesi En Zor Dizüstüler: Apple Neden Dipte? yazımıza bakabilirsiniz.
Kullanılan parça taşları
- Node.js: Uygulamanın omurgası — bunu es geçmeyin
- SociaVault API: Instagram ve TikTok’tan veri çekmek için
- Discord.js: Bildirimleri sunucuya göndermek için (bence en önemlisi)
- node-cron: Belirli aralıklarla çalıştırmak için
- SQLite / better-sqlite3: Görülen postları hafifçe saklamak için
Küçük kurulumla büyük iş yapmak mümkün mü?
Bi saniye — Evet… ama ufak bir şartla: düzenli olacaksın. Botun işi sadece post görmek değil; hangi postu daha önce gördüğünü de hatırlamak zorunda. Yoksa her taramada aynı şeyi bağırır durur. Peki bunu neden söylüyorum? Baya sinir bozucu olur bu, inanın.
Bana göre en şık taraflardan biri de.env yaklaşımıydı. Token’ları koda gömmek yerine çevresel değişkenlerde tutmak hem temiz hem güvenli — ve açık konuşayım, ileride ciddi baş ağrısını azaltıyor. Kurumsal projede bunu ihmal edenleri çok gördüm; sonra repo içinde anahtar arama macerası başlıyor, herkes birbirine bakıyor… Bu konuyla ilgili Easter Phishing Tuzağı: Bir Operasyonu Söküp Atmak yazımıza da göz atmanızı tavsiye ederim.
| Bileşen | Küçük startup için | Büyük ekip / enterprise için |
|---|---|---|
| Saklama katmanı | SQLite yeterli | PostgreSQL + audit log tercih edilir |
| Zamanlama | node-cron iş görür | Kubernetes CronJob veya queue sistemi daha iyi olur |
| Bildirim kanalı | Tek Discord sunucusu pratik | Kanal bazlı rol dağıtımı gerekir |
| Error handling | Sade retry mekanizması yeter | Circuit breaker + observability gerekir |
Nerede güçlü, nerede biraz ham?
Şöyle söyleyeyim, Dürüst olayım. Bu yapı çok kullanışlı ama kusursuz değil. Birincisi, polling tabanlı olduğu için gerçek zamanlılık sınırlı kalıyor. “tam saniyesinde” yerine “bir sonraki kontrolde” yakalıyorsun. Fark var. İkincisi ise üçüncü parti API’ye bağımlılık meselesi — API yavaşlarsa ya da limit dolarsa senin bot da beklemeye geçiyor, yapacak bir şey yok.
İşin garibi, Ama pratikte bu eksiler çoğu ekip için tolere edilebilir düzeydeydi. Mesela günde birkaç kez paylaşım yapan rakipler söz konusuysa yarım saatlik kontrol döngüsü fena değil. Hatta bazı durumlarda fazla sık kontrol etmek yerine biraz seyrek çalıştırmak daha mantıklı oluyor çünkü gereksiz trafik üretmiyorsun ve API limitlerini koruyorsun. Bu konuyla ilgili Türkiye’nin BYD Dosyası: Ceza, Fabrika ve Piyasa Gerilimi yazımıza da göz atmanızı tavsiye ederim.
Kod tarafında en kritik yerler neler?
Tam kodu burada birebir yeniden basmayacağım. Omurgayı anlamak kolay: önce veritabanında seen_posts.db açılıyor, sonra tablo oluşturuluyor, eski kayıtlar siliniyor, ardından sorgular hazırlanıyor. Bu yaklaşım güzel çünkü okuma-yazma işlemlerini sade tutuyor (ciddiyim) Bilibili Akışı Nasıl Çözülür: DASH ve FFmpeg Sırrı yazımızda da bu konuya değinmiştik.
// Basitleştirilmiş akış fikri
cron.schedule('*/30 * * * *', async () => {
const posts = await getRecentPosts(platform, username);
for (const post of posts) {
if (!hasBeenSeen(post.id)) {
await sendDiscordAlert(post);
markSeen(post.id, platform, username);
}
}
}); Dürüst olmak gerekirse, Neyse uzatmayalım. Burada esas mesele kod satırı sayısı değil, mantığın sağlam olması. Mesela benzer işleri test ederken en çok hata çıkan yer hep duplicate alert kısmıdır (inanın bana). Bir olay ilk seferde doğru çalışır ama ikinci turda aynı şeyi tekrar gönderirse tüm sistemin değeri düşer. Ekip “bu bot yalan söylüyor” moduna girer ve artık uyarılara bakmaz — bu da bütün emekten daha beter bir sonuç.
Daha sağlam hale getirmek için ne yapılabilir?
Bence ilk iyileştirme retry mekanizması olurdu. API kısa süre cevap vermezse hemen pes etmek yerine kontrollü yeniden deneme eklenebilir; üç deneme, aralarında kısa bekleme, sonra hata logu. İkinci iyileştirme ise rate limit koruması — kaç istek attığını takip etmezsen bir sabah API’nin seni geçici olarak engellediğini görürsün. O gün rakip ne paylaşmış hiç bilmezsin.
Peki Discord neden iyi seçim?
Tuhaf ama, Açık söyleyeyim, Shadcn UI 2026 — Kütüphane Değil, Sahiplik Hissi gibi araçların aksine Discord burada sadece sohbet uygulaması olmaktan çıkıp operasyon paneline dönüşüyor. Kanal içine gelen embed, takımın gözünün önünde duran canlı uyarıya benziyor. Slack de olurdu, — itiraz edebilirsiniz tabi — Teams de olurdu, hatta e-posta bile olurdu. Ama Discord’un hafifliği başka.
Geçen ay Ankara’da küçük bir SaaS ekibiyle yaptığım sohbette şunu duydum: “Biz e-postaya düşen uyarıları kimse okumuyor.” İşte tam o noktada Discord’un değeri ortaya çıkıyor. Mesaj hızlı geliyor, okunuyor, üstüne emojiyle reaksiyon bile alınabiliyor. Kültür meselesi biraz da…
Bir dakika, şunu da ekleyeyim: büyük kurumlarda kanal disiplinini sağlamak şart. Her şeyi tek kanala yığarsan sabah açtığında mini kaos görürsün. Peki bunu neden söylüyorum? O yüzden marka bazlı kanal, ülke bazlı kanal ya da ürün hattına göre ayrılmış odalar baya işe yarıyor — deneyimle söylüyorum.
Bence asıl kazanım zaman değil, dikkat ekonomisi
Bu tür otomasyonların görünmeyen faydası sadece dakika kazandırması değildir; zihni rahatlatır. İnsanlar artık “acaba rakip paylaştı mı?” diye düşünmüyor. Bot düşünür, takım karar verir. Ben bunu Şubat 2026’da kendi editör masasındaki rutinde fark ettim: sürekli sekme değiştirmekten kurtulunca gündemi yorumlamaya daha çok vakit kaldı.
Yine de hayal kırıklığı yaşayabileceğiniz yerler var. Örneğin API’nin kapsamadığı platformlar varsa sisteminiz eksik kalır. Ya da işletmenin ihtiyacı gerçek zamanlı dinleme ise polling modeli biraz ağır gelebilir. Kağıt üstünde süper görünen şey pratikte orta halli çıkabilir; kabul etmek lazım.
Sıkça Sorulan Sorular”>
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
