Sesli Sohbet Sitesi Kurma: 0’dan Yayına Alım (Altyapı, Ses Teknolojisi, Moderasyon ve Maliyet) Rehberi

“Sesli sohbet sitesi kurma nasıl yapılır?” sorusuna tek bir “DJ gibi kurulum” cevabı vermek mümkün değil; çünkü işin asıl zor kısmı düşük gecikmeli ses aktarımını (WebRTC/SFU), oda mimarisini, moderasyon süreçlerini ve yasal/uyumluluk tarafını aynı anda doğru tasarlamak. Bu rehber de tam olarak bunu yapıyor: sıfırdan yayına alım planını uçtan uca ele alıyor; hangi mimariyle ilerleyeceğinizi ve hangi bileşenleri eklemeniz gerektiğini netleştiriyor.

Bu yüzden ilk etapta kararlarınızı “sesli sohbet” denince akla gelen yalnızca kullanıcı deneyimine göre değil; altyapı seçimlerinden ölçüm metriklerine kadar uzanan tüm yaşam döngüsüne göre verin. En iyi senaryoda bile yanlış tasarım gecikmeyi artırır, maliyeti şişirir; doğru kurduğunuzda ise güvenlik ve moderasyonu baştan oturttuğunuz için büyümek daha kolay hale gelir. Aşağıda sesli sohbet sitesi kurma nasıl yapılır konusunu; mimari, ürün, UX, güvenlik, moderasyon, ölçekleme ve launch planı şeklinde adım adım ilerleteceğim.

Kapsam ve temel terimler (sesli sohbet, oda/kanal, düşük gecikme, SFU/P2P)

Sesli sohbet, kullanıcıların mikrofon aracılığıyla ses yayınlayıp aynı ortamda diğer kullanıcılarla anlık etkileşim kurduğu gerçek zamanlı bir uygulama türüdür. Burada “oda” (room/channel) fikri kritik: Kullanıcılar belirli bir oda içinde yayıncı/katılımcı rolüyle ses akışına abone olur. Ürünün başarısı da bu odalarda sesin akıcılığı ve erişilebilirliğiyle ölçülür.

Düşük gecikme (low latency), konuşma anı ile karşı tarafın duyması arasında geçen sürenin kısalığıdır. Sesli sohbetlerde hedef genelde 200–500 ms gibi düşünülür; ancak altyapı, ağ koşulları ve codec seçimi bu bandı direkt etkiler. “Jitter” (paketler arası süre dalgalanması) ve “packet loss” (paket kaybı) ise gecikmeyi artıran ya da anlaşılabilirliği düşüren iki önemli değişkendir.

SFU (Selective Forwarding Unit) ve P2P (peer-to-peer) ayrımı da başlangıçta mutlaka netleşmelidir. SFU mimarisinde ses akışları bir sunucu tarafından seçilerek yönlendirilir; P2P’de ise kullanıcılar doğrudan birbirine bağlanır. Oda tabanlı ürünlerde SFU çoğu zaman ölçeklenebilirliği artıran tercih olarak görülür.

Platform türleri: birebir, oda tabanlı, public/private; hangi senaryoda hangi mimari

Önce hangi “sesli sohbet” modelini kuracağınızı belirleyin. Birebir (1:1) görüşme; iki kullanıcının doğrudan konuştuğu en basit senaryodur. Oda tabanlı modelde ise bir konuşma alanı (ör. 5–50) üzerinden birden fazla katılımcı aynı anda ses paylaşır; bu da ürününüzün “sosyal” tarafını doğrudan taşır.

Public oda ile private oda arasındaki fark da mimari kararları etkiler. Public odalarda daha sık otomatik giriş, daha fazla kullanıcı akışı ve daha fazla kötüye kullanım denemesi görülebilir. Private odalarda ise kimlik doğrulama, davet linki ve rol bazlı erişim daha ön planda olur. Bu yüzden “kimlik doğrulama + yetkilendirme” katmanını baştan tasarlamak gerekir.

Pratik seçim şu şekilde özetlenebilir: Eğer odada eş zamanlı kullanıcı sayınız artacaksa (ör. 10, 25, 50), P2P yerine SFU ile oda tabanlı mimari daha mantıklıdır. Birebir kullanım istiyorsanız P2P hızlı bir MVP çıkarmanızı sağlar; fakat otomatik ölçek, NAT/Firewall uyumluluğu ve çoklu kullanıcı durumunda SFU’nun yönetimi genelde daha kolay olur.

Minimum ürün (MVP) tanımı ve hedef metrikler (gecikme, eş zamanlı kullanıcı, maliyet)

Sesli sohbet sitesi kurma yolculuğunun en hızlı ilerleyen kısmı genellikle “minimum ürün” fikridir. MVP’nizi, tek bir oda türüne odaklanarak kurgulayın: örneğin “public sesli sohbet odası” ve sınırlı eş zamanlı kullanıcı. Amaç; ses akışını sorunsuz yayına almak, oda sistemini çalışır hale getirmek ve temel güvenlik/raporlama akışını kurmaktır.

MVP’nin hedef metrikleri net olmalı. Örneğin: 1) Ortalama gecikme (p50/p95), 2) jitter ve packet loss dağılımı, 3) aynı anda bağlanan kullanıcı sayısı, 4) sunucu başına eş zamanlı oturum sayısı, 5) üçüncü taraf servis maliyeti. Bu metrikleri ölçmeden “çalışıyor” demeyin; gerçek kullanımda Wi‑Fi ile mobil ağ arasındaki fark gecikmeyi dramatik şekilde etkileyebilir.

Önce bir “başarı tanımı” yapın: Oda başına en az 5–10 eş zamanlı kullanıcı ile 30 dakikalık oturumlarda kesintisiz görüşme, mikrofon mute/leave akışlarında hatasız deneyim ve raporlama/ban kararlarının gecikmesiz uygulanması gibi. Sonra ölçeklemeye geçersiniz.

Teknik mimari seçenekleri: (1) sıfırdan WebRTC (SFU) (2) managed servis/3. parti ses altyapısı

Sesli sohbet sitesi kurma nasıl yapılır sorusunun omurgası mimaridir. İki ana çizgi var: kendi SFU altyapınızı kurmak veya managed/üçüncü taraf bir ses altyapısı kullanmak. Kendi SFU’nuzu kurmak daha fazla kontrol verir; fakat ekip yükü artar: sürüm yönetimi, NAT sorunları, güvenlik güncellemeleri ve performans optimizasyonu gibi başlıklar sizi daha fazla meşgul eder.

Managed servis kullanmak; oda/oturum yönetimini, WebRTC bağlantılarını, ölçeklenebilir yönlendirmeyi ve bazı güvenlik katmanlarını daha hızlı hazır sunar. Ancak maliyet birim başına (dakika/akış/GB) artabilir ve kontrolünüz kısmen sınırlanır. Bu yüzden hedef kullanıcı sayısı ve ürün stratejisini birlikte değerlendirmek gerekir.

Aşağıdaki karşılaştırma, karar sürecinizi hızlandırır:

Mimari	Artı	Eksi	Uygun Senaryo
SFU (Oda tabanlı, sıfırdan)	Kontrol ve özelleştirme; maliyeti optimize etme potansiyeli	Geliştirme + bakım yükü; performans/aksaklık debug süresi	Uzun vadeli büyüme hedefi ve teknik ekip varlığı
Managed/3. parti ses altyapısı	Hızlı MVP; daha kısa entegrasyon süresi	Birim maliyet; bazı özelleştirmelerde sınırlılık	Hızla doğrulama, pilot lansman ve bütçe/ekip sınırlılığı

Örnek olarak, SFU kullanan oda tabanlı yapı ile P2P’yi karşılaştırın: P2P’de oda büyüdükçe bağlantı sayısı kullanıcı karesine yaklaşır ve her cihazın ağ/CPU yükü artar. SFU’da ise her kullanıcının sunucuya tek ana uplink/bağlantı kurması, oda büyümesinde maliyeti daha kontrollü hale getirir. Bu fark doğrudan “sesli sohbet sitesini yayınlatma” maliyetinizi belirler.

Sunucu ve altyapı tasarımı: sinyalizasyon, kullanıcı yönetimi, oturum/room sistemi

Sesli sohbet sitesi kurma nasıl yapılır adımında “ses ile sinyalizasyonu” birbirinden ayırın. WebRTC’nin kendisi medya taşır; sinyalizasyon ise istemcilerin bağlantı kurması için gerekli bilgileri paylaşır (offer/answer, ICE candidate gibi). Bu katman genelde WebSocket tabanlı bir sinyalizasyon sunucusuyla yönetilir.

Kullanıcı yönetimi tarafında kimlik doğrulama (JWT/OAuth), yetkilendirme (oda erişimi, rol) ve oturum yönetimi (session token) tasarlanmalıdır. Oda/room sistemi ise en az şu kavramları içermelidir: oda kimliği, oda tipi (public/private), üye listesi, yayıncı sayısı, kullanıcıların statüsü (joined/speaking/muted) ve kapasite limiti.

Oturum akışında “state” tutarlılığı özellikle önemlidir. Örneğin kullanıcı leave dediğinde hem istemci tarafında medya akışı kapatılmalı hem de sunucu tarafında oda üyeliği güncellenmelidir. Bu senkronize olmazsa “hayalet kullanıcı” gibi sorunlar doğar ve moderasyon işini gereksiz şekilde zorlaştırır.

Uygulama akışları: kullanıcı kaydı/giriş, oda oluşturma/katılma, mikrofon kontrolü, mute/leave

Bir sesli sohbet sitesi; sadece “ses akışı” değildir, aynı zamanda net ürün akışlarıdır. Önce kayıt/giriş akışını belirleyin: misafir giriş mi olacak, e-posta doğrulama mı, SMS doğrulama mı? MVP’de basit bir giriş yeterli olabilir; fakat public odalarda kimliksiz girişin abuse riskini artırdığını da unutmayın.

Oda oluşturma ve katılma akışını baştan tasarlayın. Örneğin şöyle düşünebilirsiniz: kullanıcı giriş yapar, oda listesi/arama ekranından room seçer ya da “create room” ile yeni oda açar; ardından mikrofonu etkinleştirir ve ses yayınlamaya başlar. Sunucu da kullanıcıyı oda durumuna alır ve diğer katılımcılara abone olma/akış yönetimi sinyallerini gönderir.

Örnek oda oluşturma/katılma akışı şu mantıktadır (kullanıcı→room→yayın/abonelik):

• Kullanıcı giriş yapar (token doğrulanır).
• Room talebi gelir: “roomId/oda tipi” kontrol edilir (public ise açık, private ise davet linki/izin gerekir).
• Join: Sunucu kullanıcıyı oda üyesi olarak işaretler, kapasiteyi kontrol eder.
• Publish/Subscribe: Kullanıcının mikrofon durumu okunur; “speaking” değilse sadece dinleme, mikrofon açık ise yayın (publish) yapılır.
• Mute/Unmute: Kullanıcı mute dediğinde sunucu “medya akışı”nı keser/akışı susturur ve oda içi durumu günceller.
• Leave: Kullanıcı ayrıldığında medya kapanır, oda üye listesi güncellenir ve diğer istemcilere kapanma sinyali gönderilir.

Bu akışları UI tarafında “hata verdiğinde ne olacak?” perspektifiyle birlikte düşünün. Örneğin tarayıcı mikrofon iznini reddederse kullanıcıya net mesaj gösterilmeli; “join” yapılmış olsa bile yayın başlatılmadan dinlemeye geçilebilmeli veya tekrar izin isteme akışı çalışmalıdır.

Örnek MVP: “5-odalı public sesli sohbet” için modül listesi ve iş akışı

Şimdi somutlaştıralım. Örnek MVP’nizi şöyle kurun: 5 adet public oda (sabit veya yarı dinamik), kullanıcıların yalnızca giriş yapıp odaya katılabildiği; mikrofonu açıp konuşabildiği ve temel mute/leave işlemlerinin sorunsuz ilerlediği bir sistem. Böylece ses akışını, oda sistemini ve moderasyonun en kritik kısmını birlikte doğrularsınız.

Modül listesi (minimum): kimlik doğrulama, oda listesi, oda join/leave servisleri, WebRTC sinyalizasyon servisi, medya yönlendirme (SFU veya managed), kullanıcı mikrofon durumu (speaking/muted), raporlama UI + API, basit moderasyon paneli (ban/uyarı) ve temel loglama/izleme.

İş akışı örneği: Kullanıcı uygulamaya girer, oda seçer; oda join olur; mikrofon izinleri alınır; speaking açılınca yayın başlar; kullanıcı mute olunca yayın durur; moderatör bir kullanıcıyı rapor/ihlale göre uyarır veya banlar. Ban sonrasında kullanıcı aynı oda yerine başka bir yerde dinleyebilecek mi, yoksa tüm platform mu engellenecek? MVP’de bu kararı şimdiden netleştirin.

Gecikme optimizasyonu ve ses kalitesi: örnekleme, bitrate, jitter buffer, adaptif akış

Gecikme optimizasyonu; codec, bitrate ve ağ koşullarıyla birlikte düşünülür. İlk adım olarak örnekleme oranını ve codec profilini doğru seçin. Sesli sohbetlerde genellikle Opus codec kullanımı; geniş uyumluluk ve iyi sıkıştırma performansı sunduğu için tercih edilir. Bitrate’ı aşırı yükseltmek kaliteyi her zaman dramatik artırmaz; maliyeti ve paket kaybı riskini artırabilir.

Jitter buffer, paket dalgalanmalarını telafi etmek için ek bir bekleme oluşturur. Bu buffer küçük olursa gecikme azalır ama anlaşılırlık düşebilir; buffer büyürse gecikme artar. Burada hedefiniz “p95 gecikme” ile “konuşma anlaşılabilirliği” dengesini tutturmak. Ayrıca adaptif akış (bitrate düşürme/yükseltme) stratejisi, kötü ağ koşullarında kırılmayı azaltır.

Uygulama içinde gecikme optimizasyonunu ölçmeye bağlayın. Ses kalitesi şikayetleri sık sık “benim internetim yavaş” diye açıklanır; oysa siz jitter ve packet loss dağılımına bakmadan kök nedeni yakalamakta zorlanırsınız. En düşük gecikmeyi hedeflerken aynı zamanda kararlılık (reconnect/ICE restart) planı da mutlaka olmalıdır.

Güvenlik ve kötüye kullanım önlemleri: kimlik doğrulama, yetkilendirme, rate limit, abuse raporlama

Güvenlik yalnızca hesap güvenliği değildir; sesli platformlarda abuse (spam, taciz, flood) doğrudan kullanıcı deneyimini ve hukuki riski etkiler. Bu nedenle kimlik doğrulama ve yetkilendirmeyi oda seviyesinde kurun. Public odada bile “kimliğini doğrulamadan konuşma” ya da “konuşmaya kısıtlı geçiş” gibi korumalar düşünebilirsiniz.

Rate limit ve davranış sınırları en sık işe yarayan önlemlerdendir. Örneğin oda join rate limiti, raporlama/şikayet gönderim rate limiti, mikrofon toggle sayısına limit gibi mekanizmalar abuse’u azaltır. Ayrıca sinyalizasyon uçlarına saldırı gelebileceğini varsayarak bot tespiti ve doğrulama (CAPTCHA veya proof-of-work) planı yapın.

Abuse raporlama süreci net olmalıdır. Kullanıcı raporladığında; hangi gerekçeyle raporlandığını, hedef kullanıcıyı ve olay anını toparlayın. Sesli sohbetlerde “ne zaman oldu?” bilgisi moderatörün karar vermesini hızlandırır. Loglama yaparken KVKK kapsamında minimum veri ilkesini gözetin.

Moderasyon: otomatik filtre + insan moderatör süreçleri, kayıt/uyarı politikası

Moderasyon tasarımı ürünün kalitesini belirler. MVP’de bile en azından “otomatik + manuel” hibrit yaklaşımı düşünün. Otomatik kısım; raporlama eşiğine göre uyarı/temporary mute, aşırı konuşma/flood tespiti ve basit kelime/etiket filtreleri gibi mekanizmaları içerebilir. Manuel kısım ise moderatörün raporları inceleyip ban kararı vermesidir.

Kayıt/uyarı politikası da şeffaf olmalı. Her platform “otomatik recoding” yapmak zorunda değildir; bazı durumlarda yalnızca rapor üzerine olay anına yakın kayıt/inceleme yapılması tercih edilir. Ancak bu yaklaşımın teknik ve yasal tarafını önceden netleştirmek gerekir. Aksi halde hem teknik hem hukuki belirsizlik büyür.

Moderasyon örneği: Raporlama + hızlı ban karar akışı (örnek policy):

• 1. Kademe (otomatik uyarı): Aynı odada 5 dakika içinde 3 rapor alan kullanıcıya uyarı mesajı + 10 dakikalık konuşma kısıtı uygulanır.
• 2. Kademe (manual review): 15 dakikada 5 rapor veya tek raporda “ciddi taciz” gerekçesi işaretlenirse moderatör hızlı inceleme kuyruğuna düşer.
• 3. Kademe (hızlı ban): Moderatör doğrularsa 24 saat ban; tekrarında kalıcı ban/seri ban uygulanır.

Bu akışların UI tarafında kullanıcıya “neden kısıtlandım?” sorusunu açıklayacak kadar bilgi vermesi gerekir. Aksi halde platform güveni düşer ve raporlar artar.

Yasal/uyumluluk checklist’i (Türkiye odaklı genel çerçeve)

Sesli sohbet sitesi kurma nasıl yapılır sorusunun önemli bir parçası yasal uyumluluktur. Türkiye odaklı genel çerçevede KVKK çerçevesi; kullanıcıların kişisel verilerinin toplanması, işlenmesi ve saklanmasıyla ilgili yükümlülükler getirir. Ses verisi, çoğu senaryoda kişisel veri kapsamına girebildiği için saklama, erişim ve imha politikalarını baştan kurgulayın.

Kullanıcı sözleşmesi ve aydınlatma metinlerini hazırlayın. Ayrıca “içerik ihlali süreçleri” için platformun nasıl hareket ettiğini genel hatlarıyla yazın: raporlama kanalı, moderasyon değerlendirme süresi, uyarı/ban kriterleri gibi. Bu metinler teknik kararlarınızla uyumlu olmalıdır; örneğin recoding yapıyorsanız bunun amacı ve kapsamı netleşmelidir.

Genel bilgilendirme olarak bir checklist önerisi: KVKK aydınlatma, kullanıcı sözleşmesi, içerik ihlali politikasının yayınlanması, raporlama kanalı ve süreç tanımı, yetkisiz erişime karşı güvenlik tedbirleri. Eğer AB kullanıcıları da olabilirseniz ayrıca GDPR benzeri çerçeveleri de değerlendirin.

Ölçekleme ve maliyet: bant genişliği, eş zamanlı kullanıcı tahmini, stres testi

Ölçekleme planı olmadan büyümek, sesli sohbet platformlarında maliyeti hızla uçurabilir. Ses akışı maliyetinin başlıca kalemleri: bant genişliği (ingress/egress), SFU/medya sunucusu kapasitesi, sinyalizasyon sunucusu yükü, üçüncü taraf managed kullanım ücreti ve gözlemlenebilirlik (log/metrics) altyapısıdır.

Önce eş zamanlı kullanıcı tahmininizi gerçekçi kurun. Örneğin “kayıtlı kullanıcı” sayısı ile “eş zamanlı” aynı şey değildir. Sıcak saatlerde odalara giriş oranı, kullanıcıların konuşma süresi ve aynı anda mikrofon açık olanların oranı (active speaker ratio) maliyeti belirler. Bu oranı pilot testte ölçmek çok değerlidir.

Maliyet örneği: 1.000 eş zamanlı kullanıcı için kaba maliyet kalemleri (bant genişliği + sunucu + üçüncü taraf kullanımı). Net hesap her sağlayıcıda farklıdır; ama yaklaşım şöyle düşünün: Opus 48 kbps–64 kbps arası bir konuşma profili ve kişi başına uplink + downlink çarpanları. Oda tabanlı SFU’da genellikle kişi başına tek sunucu uplink vardır; downlink ise subscribe edilen akış sayısına bağlıdır. Eğer odada ortalama 10 kişi varsa, her kullanıcı yaklaşık 9 akıştan abonelik alabilir; SFU bunu verimli yönlendirebilir ama bant genişliği yine de en büyük kalemlerden biridir.

Üçüncü taraf managed servis kullanıyorsanız dakikaya/akışa/transfer’a dayalı faturalama görebilirsiniz. Bu nedenle pilotte “ortalama bitrate” ve “aktif konuşma yüzdesini” ölçüp birim maliyeti çıkarın. Sonra stres testi yaparak pik saat maliyetini hesaplayın.

Yayına alım planı: test ortamı, pilot oda, performans ve güvenlik testleri

Yayın öncesi plan yapmak, teknik riskleri azaltır. Önce staging/test ortamını kurun; aynı oda mantığını ve aynı kimlik doğrulama akışını kullanın. WebRTC testlerinde NAT türleri, farklı tarayıcılar (Chrome/Firefox/Safari), mobil ağlar ve farklı cihaz mikrofon izinleri mutlaka test edilmelidir.

Pilot oda ile başlayın: Örneğin 5–odalı public MVP’nizi önce sınırlı kullanıcı ile açın. Bu aşamada hem gecikme hem de güvenlik sinyallerini toplayın. Performans testinde sadece “bağlantı kuruluyor mu?” değil; konuşma sırasında packet loss artıyor mu, reconnect süreleri uzuyor mu, oda yönetimi tutarlı mı gibi sorulara cevap bulun.

Güvenlik testleri de aynı önemdedir. Rate limit davranışı, raporlama endpoint’lerinin kötüye kullanım dayanımı ve ban kararlarının yayılması (propagation) test edilmelidir. En kritik şey: kötüye kullanım anında kullanıcılar tamamen kopmasın, moderasyon “hızlı tepki” verebilsin.

Beklenen performansı nasıl kontrol edilir (adım adım doğrulama)

Sesli sohbet sitesi kurma sürecinde “yayına yaklaşıyoruz” dediğinizde bile kör noktalar kalır. Bu yüzden performansı doğrulamak için net kontrol adımlarını devreye alın. Aşağıdaki adımlar, adım adım doğrulama mantığıyla çalışır:

1. Gecikme ve jitter testi: Aynı odada farklı cihazlarla 15 dakikalık konuşma yapın, p95 gecikme/jitter değerlerini kaydedin.
2. Network simülasyonu: Packet loss ve jitter simülasyonu uygulayın; adaptif akışın bitrate düşürüp düşürmediğini doğrulayın.
3. Oda state tutarlılığı: Kullanıcı join/leave/mute/unmute işlemlerini hızlı tekrar edin; oda üye listesi ve yayın durumu senkron mu bakın.
4. Abuse/rapor akışı: Bot senaryosu gibi raporlama göndererek rate limit ve moderatör pipeline’ının bozulmadığını doğrulayın.

Bu testler sonunda elde ettiğiniz veriyi “hedef metriklerle” karşılaştırın. Eğer p95 gecikme veya packet loss kabul edilemez seviyedeyse, codec/bitrate ayarı, jitter buffer ve yayıncı sayısı abonelik stratejisi yeniden değerlendirilmelidir.

Yaygın hatalar, sık yapılan hatalar ve kaçınılması gerekenler

Sesli sohbet platformlarında en pahalı hatalar genellikle erken aşamada yapılır. İlk hata “mimari seçimi UX’e göre değil maliyete/ölçüme göre yapmak” olur. Örneğin odada büyüme olasılığını düşünmeden P2P’ye odaklanırsanız kullanıcı sayısı arttıkça gecikme ve bağlantı hataları artabilir.

İkinci hata; moderasyonu sonradan düşünmektir. İlk gün bile raporlama UI’si, ban/uyarı politikası ve loglama yoksa, problem büyür ve müşteri desteği yükü artar. Üçüncü hata ise KVKK/aydınlatma metinlerini “sonra yazarız” diyerek ertelemektir. Ses verisi ve kayıt süreçleri doğru tasarlanmazsa teknik borç ile hukuki risk birlikte büyür.

Kaçınma yaklaşımı: MVP’yi küçük tutun ama güvenlik ve moderasyonun çekirdeğini ekleyin. Ayrıca “kayıt yapmıyoruz” derseniz bile, teknik loglama ve olay inceleme süreçlerinin kapsamını yine de netleştirin.

Başlangıç kontrol listesi (launch checklist)

Launch’a yaklaşırken son bir kontrol listesi yapın. Buradaki amaç; “çalışıyor gibi” görünen ama sahada sorun çıkaran küçük detayları yakalamak. Özellikle oda state senkronu, mikrofon izin akışı, raporlama endpoint’leri ve ban propagation gözden kaçarsa büyük kriz yaşanır.

Kontrol listesi: kimlik doğrulama (token, session), oda oluşturma/katılma, WebRTC sinyalizasyon, SFU/managed bağlantı doğrulama, mute/leave çalışması, gecikme/p95 hedefleri, güvenlik (rate limit + yetkilendirme), moderasyon pipeline (rapor → inceleme → uyarı/ban), KVKK aydınlatma ve kullanıcı sözleşmesi, loglama/izleme ve rollback planı.

İsterseniz bu makalenin devamında; kullanıcıyı odaya alıştıracak akışları ve ilk etkileşimi tasarlamaya da geçin: sesli sohbette kullanıcıyı odaya alıştırma için ilk temas/akış. Ayrıca moderasyon tasarımının “topluluk normları” tarafını da güçlendirmek için topluluk normları ve moderasyon tasarımına temel içeriğini inceleyin.

SSS (SFU mu P2P mi?, gecikme, MVP, moderasyon, mute/rapor/ban, kayıt ve metrikler)

SFU mu P2P mi seçmeliyim? Ne zaman hangisi daha mantıklı?
P2P genelde birebir veya çok küçük grup senaryolarında daha hızlı başlayabilir. Oda büyüyecekse (çoklu kullanıcı) SFU daha ölçeklenebilir olur; bağlantı karmaşıklığını ve cihaz yükünü azaltır.

Sesli sohbette en düşük gecikmeyi nasıl hedeflerim?
Opus/codec parametrelerini doğru seçin, bitrate’ı aşırı şişirmeyin, jitter buffer’ı gecikme hedefinize göre ayarlayın ve adaptif akışı aktif edin. En önemlisi p50/p95 ölçümü yaparak optimizasyonu veriye bağlayın.

MVP’yi en hızlı nasıl çıkarırım: sıfırdan mı API ile mi?
Zaman/kaynak kısıtlıysa managed servis ile pilot çıkarın; sonra metriklere göre SFU’ya geçiş planı yapabilirsiniz. Sıfırdan kurulum ise güçlü bir teknik ekip ve uzun vadeli ölçek hedefi gerektirir.

Moderasyon nasıl kurgulanmalı (otomatik vs manuel)?
Otomatik filtreyi rapor eşiği, rate limit ve temel kural ihlallerinde kullanın; ağır vakalar ve tartışmalı durumlar için manuel inceleme ekleyin. Hızlı ban karar akışı, caydırıcılık sağlar.

Kullanıcıların sesini kapatma/mute, raporlama ve ban süreçlerini nasıl yönetirim?
Mute komutu istemci + sunucu tarafında senkron çalışmalı, raporlama olay bilgisiyle (neden, zaman, hedef) toplanmalı ve ban kararı kullanıcıya hızlı yansıtılmalıdır. Propagation gecikirse “ban etkisizmiş” algısı oluşur.

Kayıt (recoding/recording) yapmak yasal olarak ve teknik olarak nasıl planlanır?
KVKK kapsamını göz önünde bulundurun, kayıt amaçlarını ve saklama sürelerini netleştirin. Teknik tarafta ise yalnızca ihtiyaç halinde kayıt (ör. rapor sonrası) veya olay inceleme penceresi kurgulayın; her durumda kullanıcı bilgilendirmesi gerekir.

Eş zamanlı kullanıcı sayısı arttıkça maliyet nasıl kontrol edilir?
Aktif konuşan oranını izleyin, oda kapasitesini ve abonelik stratejisini optimize edin, bitrate/codec profillerini ayarlayın ve stres testte pik değerleri esas alın. Managed kullanımda birim maliyeti pilotte hesaplayın.

Hangi metrikleri (gecikme/jitter/packet loss) izlemeliyim?
p50/p95 gecikme, jitter, packet loss, reconnect süreleri, oda join/leave hata oranları, kullanıcı başına ortalama bitrate ve SFU/medya sunucusu kaynak kullanımı (CPU/RAM) gibi ölçümler kritik.

Son olarak; sesli sohbet sitesi kurma nasıl yapılır sorusunun cevabı tek bir teknoloji seçimi değil, doğru mimari + doğru ürün akışı + güvenlik/moderasyon uyumu + ölçülebilir hedefler bütünüdür. Siz bu rehberdeki karar çerçevesiyle ilerledikçe, büyüme sırasında sürpriz maliyet ve kalite sorunlarıyla karşılaşma ihtimaliniz ciddi şekilde düşer.

İsterseniz yayını/rol yönetimini nasıl kurgulayacağınızı da bir sonraki adım olarak düşünün: yayıncı/DJ rol yönetimi ve kuralların nasıl kurgulanacağı.