Giriş Akışını Bozmadan SMS Doğrulama Sağlayıcısı Değiştirme

Sağlayıcı Geçişleri Neden Ters Gider

SMS doğrulama sağlayıcınızı değiştirmek kulağa basit gelir. Yeni bir yere kaydolursunuz, bir API anahtarını değiştirirsiniz ve yayına alırsınız. Sonra destek talepleri başlar. Bir ülkedeki kullanıcılar kod almayı keser. Tekrar deneme mantığınız çift ücret keser. Sabahın ikisinde sabit kodlanmış bir yanıt biçimi sessizce bozulur.

Giriş akışı, her üründeki en kırılgan parçalardan biridir. Bir kullanıcı OTP alamıyorsa içeri giremez. Bu, gerçek zamanlı yaşanan bir kayıptır. Yani geçişin amacı sadece daha iyi bir sağlayıcıya taşınmak değildir. Amaç, tek bir kullanıcı bile fark etmeden taşınmaktır.

Bu rehber, giriş akışınızı kutsal sayan bir geçiş planını adım adım anlatıyor. Soyutlama, çift çalıştırma, kademeli dağıtım ve geri alma konularını ele alacağız. Hiçbiri kahramanlık gerektirmiyor. Sadece işleri doğru sırayla yapmayı gerektiriyor.

Adım 1: Sağlayıcıyı Bir Arayüzün Arkasına Soyutlayın

Kodunuz eski sağlayıcının SDK'sını doğrudan giriş denetleyicinizden çağırıyorsa burada durun. Geçişleri acı verici yapan tam da bu bağımlılıktır.

Her sağlayıcı çağrısını iki işlemli ince bir arayüzün arkasına sarın: kodGonder(telefon, kanal) ve koduDogrula(telefon, kod). Uygulamanız yalnızca bu arayüzle konuşur. Arkasındaki somut uygulama bugün eski sağlayıcı, yarın yeni sağlayıcı olabilir.

Minimum bir sözleşme şöyle görünebilir:

interface SmsVerifier {
  kodIste(telefon: string): Promise<{ istekId: string }>
  koduKontrol(istekId: string, kod: string): Promise<DogrulamaSonucu>
}

Arayüzü sağlayıcıdan bağımsız tutun. Tescilli bir durum sabiti gibi satıcıya özel alanların iş mantığınıza sızmasına izin vermeyin. Her şeyi kendi tiplerinize normalleştirin: BEKLEMEDE, DOGRULANDI, SURESI_DOLDU, BASARISIZ. Yeni sağlayıcıyı eklediğinizde aynı arayüzün ikinci bir uygulamasını yazarsınız ve üst katmanda hiçbir şey değişmez.

Bu katmanı sıfırdan kuruyorsanız, geliştiriciler için SMS doğrulama API rehberimiz çoğu sağlayıcının paylaştığı istek ve durum kalıplarını gösterir, bu da normalleştirmeyi kolaylaştırır.

Adım 2: İki API'yi Alan Alan Eşleştirin

Yeni uygulamanın tek satırını yazmadan önce bir çeviri tablosu oluşturun. Eski sağlayıcının kavramlarını bir sütuna, yeni sağlayıcınınkileri diğerine koyun.

Sık farklılık gösteren şeyler:

• Kod teslim modeli. Bazı sağlayıcılar kodu gönderir ve kendi taraflarında doğrulamanıza izin verir. Diğerleri kodu size döner ve karşılaştırmayı siz yaparsınız. Bunlar birbirinin yerine geçmez ve tüm doğrulama yolunuzu değiştirir.
• Durum adları. teslim edildi, gönderildi, tamamlandı ve başarılı farklı şeyler ifade edebilir. Dokümanları okuyun, varsaymayın.
• Hız limitleri ve tekrar denemeler. Numara başına saatte üç gönderime izin veren bir sağlayıcı, mevcut tekrar deneme döngünüzde farklı davranır.
• Ülke ve kanal kapsamı. Kullanıcılarınızın bulunduğu her ülkenin desteklendiğini geçişten önce doğrulayın.
• Hata kodları. Her hatayı zaten sahip olduğunuz kullanıcıya dönük bir mesaja eşleyin.

Bu haritayı yazın. Daha sonra test kontrol listeniz olur. Bir durumun karşılığı yoksa, bu geçişten sonra değil önce çözülmesi gereken bir uyarı işaretidir.

Adım 3: İki Sağlayıcıyı Paralel Çalıştırın

En güvenli geçişler asla bir düğmeye basmaz. Bir sağlayıcıyı söndürürken diğerini yavaşça yakarlar.

Belirli bir isteği hangi uygulamanın işleyeceğine karar veren bir özellik bayrağı veya yapılandırma değeri ekleyin. Yeni sağlayıcının trafiğin yüzde sıfırını işlemesiyle başlayın. Dağıtın. Kullanıcılar için hiçbir şey değişmez ama yeni kod yolu artık canlı ve erişilebilir.

Sonra küçük bir dilimi, örneğin dahili test hesaplarını ve personel numaralarını yeni sağlayıcıya yönlendirin. Gerçek telefonlara gerçek kodlar gönderin. Ulaştıklarını, hızlı ulaştıklarını ve doğru doğrulandıklarını kontrol edin. OTP'leriniz yavaşsa veya eksikse, bir OTP kodunun neden hiç gelmediğine dair incelememiz, sağlayıcı sorununu yönlendirme veya filtreleme sorunundan ayırmanıza yardımcı olur.

Adım 4: Yüzdeyle Kademeli Dağıtın

Dahili trafik temiz göründüğünde kapıyı genişletin. Mantıklı bir rampa:

1. Gerçek kullanıcıların yüzde 1'i 24 saat boyunca.
2. Bir iki gün boyunca yüzde 10'u.
3. Metrikler tutunca yüzde 50'si.
4. Emin olduğunuzda yüzde 100'ü.

Her aşamada sağlayıcı başına üç sayıyı izleyin:

• Teslim oranı (cihaza ulaşan gönderilen kodlar).
• Doğrulama başarı oranı (akışı tamamlayan kullanıcılar).
• Teslim süresi (medyan ve 95. yüzdelik).

Bunları ülkeye göre bölümlere ayırın. Bir sağlayıcı toplamda mükemmel görünürken bir bölgede sessizce başarısız olabilir. Herhangi bir bölümde doğrulama başarısı düşerse, dağıtımı durdurun ve genişletmeden önce araştırın.

Rampayı her adımda geri alınabilir tutun. Yüzde kapısının tüm amacı, onu kısmanın anında ve güvenli olmasıdır.

Adım 5: Yalnızca Bir Anahtar Değil, Gerçek Bir Yedek Kurun

Geçiş, muhtemelen her zaman ihtiyaç duyduğunuz dayanıklılığı eklemek için iyi bir andır. A sağlayıcısından B sağlayıcısına sert bir geçiş yerine, ikisini de bağlı tutun ve sisteminizin otomatik yedeğe geçmesine izin verin.

Mantık basit. Birincil sağlayıcıyı deneyin. Gönderim kısa bir pencere içinde başarısız olursa veya zaman aşımına uğrarsa, aynı kullanıcıyı ikincil sağlayıcıda tekrar deneyin. Kullanıcı sadece bir kodun geldiğini görür. İki sistemin dahil olduğunu asla bilmez.

Bu kalıp, geçişinizi kalıcı bir yükseltmeye dönüştürür. Sağlayıcı yük devretmeli SMS doğrulama API'si kurma rehberimizde daha derin bir uygulama anlatımı okuyabilirsiniz. Ana kural: tek bir sağlayıcı kesintisinin asla bir giriş kesintisi anlamına gelmesine izin vermeyin.

Çift gönderimlere karşı önlem alın. Yedeğe geçtiğinizde ilk denemeyi iptal edin veya yok sayın ki kullanıcı iki kod almasın ve hangisini gireceği konusunda kafası karışmasın.

Adım 6: İdempotansı ve Uçuştaki Oturumları Koruyun

Geçiş sırasında bazı kullanıcılar giriş yapmanın ortasında olacak. Eski sağlayıcıdan bir kod istediler ve henüz girmediler. Onlar göndermeden önce doğrulamayı yeni sağlayıcıya geçirirseniz, geçerli kodları aniden başarısız olur.

Bunu daha önce döndürdüğünüz istekId ile yönetin. Her bekleyen doğrulamayı hangi sağlayıcının verdiğini saklayın. Kod geri geldiğinde, mevcut varsayılan ne olursa olsun kontrolü kodu gönderen sağlayıcıya yönlendirin. Bekleyen doğrulamalar her zaman orijinal düzenleyicilerine karşı çözülmelidir.

Uçuştaki kodlara normal sona erme sürenize eşit bir tolerans süresi verin, genellikle beş ila on dakika. Ancak o pencereden sonra eski sağlayıcı boşta sayılmalıdır. Bu tek ayrıntı, en yaygın geçiş şikayetini önler: "kodum çalışmayı kesti."

Adım 7: Yalnızca Mutlu Yolu Değil, Hata Yollarını Test Edin

Her şey çalışırken bir kodun geldiğini herkes doğrulayabilir. Geçişler kenarlarda kırılır. Tam dağıtımdan önce kasıtlı olarak test edin:

• Yanlış kod girişi doğru hatayı döndürür.
• Süresi dolmuş kod temizce reddedilir.
• Hız limitli bir numara mantıklı bir mesaj gösterir.
• Sağlayıcı zaman aşımı yedeğinizi tetikler.
• Desteklenmeyen ülke gönderimden sonra değil önce yakalanır.

Bunları sahte bir sağlayıcı kullanarak arayüzünüze karşı otomatik testler olarak yazın. Böylece her çalıştırmada canlı mesajlara harcama yapmadan her iki uygulamanın aynı davrandığını kanıtlayabilirsiniz. Canlı gönderime ihtiyaç duyduğunuzda, önemsediğiniz birkaç ülkede küçük bir gerçek numara havuzu kullanın.

Adım 8: İhtiyaç Duymadan Önce Geri Almayı Planlayın

Geri alma bir başarısızlık değildir. Bir özelliktir. Her şeyi bir bayrağın arkasına kurduğunuz için geri almak, yüzdeyi sıfıra ayarlamaktan ibarettir. Yeniden dağıtım yok, kod değişikliği yok, panik yok.

Kesin tetikleme koşullarını önceden yazın. Örneğin: herhangi bir büyük ülkede doğrulama başarısı on beş dakikadan uzun süre birkaç puandan fazla düşerse geri al. Eşiği baskı altında belirlemek kötü kararlara yol açar. Sakinken belirlemek sakin bir tepkiye yol açar.

Yeni sağlayıcı en az tam bir faturalama ve kullanım döngüsü boyunca yüzde 100'de çalışana kadar eski sağlayıcı hesabını aktif ve bakiyeli tutun. Çok erken iptal etmek güvenlik ağınızı ortadan kaldırır.

Geçiş Yapmaya Değer Bir Sağlayıcı Seçmek

Geçiş mekaniği önemlidir ama hedef de önemlidir. Yeni bir SMS doğrulama sağlayıcısını değerlendirirken şunları kontrol edin:

• Pazarlama haritasıyla değil, gerçek kullanıcı tabanınızla eşleşen ülke kapsamı.
• Sürpriz ülke primleri olmayan şeffaf fiyatlandırma.
• Arayüz uygulamanızın ince kalması için kararlı, iyi belgelenmiş bir API.
• Kullanıcılarınızın doğruladığı belirli hizmetler için güvenilir teslimat, örneğin mesajlaşma uygulamaları ve sosyal platformlar.

SMSBulk, 200'den fazla ülkede doğrulama numaraları kapsar ve yukarıda anlatılan soyutlamaya düzgünce oturan temiz bir SMS doğrulama API'si sunar. Geliştirici dokümantasyonu istek ve durum modelini ortaya koyar, böylece ikinci uygulamanızı hızlıca kurabilirsiniz. Aynı hesap ve cüzdan seyahat eSIM'lerini de çalıştırdığı için, küresel ölçekte iş yapan ekipler birden fazla yerine tek bir faturalama ilişkisi elde eder.

Gerçekçi Bir Geçiş Zaman Çizelgesi

Tipik bir SaaS ürünü için dikkatli bir geçiş şöyle görünür:

• 1. Hafta: Arayüzü kurun, mevcut çağrıları arkasına taşıyın, eski sağlayıcı hâlâ yüzde 100'deyken yayına alın. Kullanıcılar hiçbir şey fark etmez.
• 2. Hafta: Yeni sağlayıcıyı uygulayın, alan eşleştirme testlerini çalıştırın, dahili hesapları yönlendirin.
• 3. Hafta: Yüzde 1'den 10'a rampalayın, metrikleri ülkeye göre izleyin.
• 4. Hafta: Yüzde 50'den 100'e rampalayın, yedeği ve eski hesabı canlı tutun.
• 5. Hafta: Tam bir döngü boyunca istikrarı doğrulayın, ardından eski sağlayıcıyı devreden çıkarın.

Burada daha yavaş, daha hızlıdır. Fazladan bir hafta süren ama kimseyi uykusundan etmeyen bir geçiş, bir hafta sonunuza ve bir grup kızgın kullanıcıya mal olan aynı gün geçişinden daha iyi bir geçiştir.

SMSBulk ile Başlayın

Bir taşıma planlıyorsanız, SMSBulk size temiz bir API, 200'den fazla ülke kapsamı, şeffaf fiyatlandırma ve tam da bu tür bir çabasız ikinci uygulama için tasarlanmış dokümantasyon sunar. Bir hesap oluşturun, seyahat eSIM'lerini ve e-posta doğrulamasını da kapsayan ortak bir cüzdana bakiye yükleyin ve ölçeklendirmeden önce teslimatı test etmek için trafiğin küçük bir dilimini yönlendirin. Giriş akışınız bozulmadan kalır, kullanıcılarınız oturumda kalır ve geçişiniz sıkıcı kalır. Tam da olması gerektiği gibi.