Vowly Event'in mühendisliği: dijital düğün davetiyeleri ve online RSVP
Bir düğün davetiyesi, şık giyinmiş bir dağıtık sistem problemidir: tek bir mesaj, yüzlerce alıcı ve düğün haftasına kadar değişmeye devam eden bir davetli listesi.
Vowly Event kulağa basit gelen bir iş yapıyor: dijital düğün davetiyeleri gönderiyor ve yanıtları online topluyor. Tek bir çift, tek bir davetli listesi ve her birinin kişisel bir şey alıp bir şey geri göndermesi gereken yüzlerce insan. Ürünü biz kuruyor ve işletiyoruz; göründüğünden zor olan kısımlar hakkında düşünme biçimimiz şöyle.
Asıl ürün davetli listesidir
Çoğu kişi davetiyenin ürün olduğunu sanır. Değildir. Davetiye görünen yüzeydir; asıl yükü taşıyan şey davetli listesidir. Liste durmadan düzenlenir, düğün haftasına kadar. İsimler düzeltilir, artı birler eklenir, bir ebeveynle yapılan telefon görüşmesinden sonra koca bir aile eklenir ve birkaç kişi sessizce çıkarılır.
Bu da veri modelinin bir davetliyi "bir kez yazılan satır" olarak görememesi demek. Davetli küçük bir geçmiştir: davet edildi, görüntüledi, yanıtladı, fikrini değiştirdi, geri döndü. Yalnızca güncel durumu modellerseniz çiftlerin gerçekten sorduğu soruyu cevaplayamazsınız — soru "kaç kişi geliyor" değil, "kim hâlâ yanıt vermedi ve acaba davetiyeyi açtı mı bile".
Bireyler değil, haneler
Kendini ikinci kez amorti eden modelleme kararı gruplamadır. Davetiyeler kişilere değil hanelere gider. Dört kişilik aile tek davetiye alır ve tek yanıt verir; ama oturma planı, ikram sayısı ve diyet notları bireyleri gerektirir. Bunu baştan yanlış kurarsanız sonraki her özellik bu hatanın etrafından dolaşmak zorunda kalır. Davetli varlığı ile davetiye varlığı ilk commit'ten itibaren ayrı olmalı.
Dalgalar hâlinde gelen trafik
Düğün trafiği düzgün bir eğri çizmez. Çift pazar akşamı davetiyeleri gönderir ve listenin büyük bölümü sonraki iki saat içinde bağlantıyı açar. Sonra bir hafta neredeyse hiçbir şey olmaz. Sonra hatırlatma çıkınca ikinci bir zirve gelir.
Bu şekil belirli tercihleri ödüllendirir. Davetiye sayfasının kendisi statik ya da statiğe yakın olmalı ve kenar önbelleğinden servis edilmeli; çünkü hanedeki herkes için aynıdır ve dalgayı asıl o karşılar. Yazma yolu — yani RSVP gönderimi — gerçekten veritabanına gitmesi gereken tek kısımdır ve isteklerin çok küçük bir bölümüdür. İkisini ayırmak, pahalı altyapının görüntülenmeler için değil yalnızca yanıtlar için boyutlandırılması anlamına gelir.
Zor olan gösterişsiz kısım: teslimat
Birkaç yüz mesaj göndermek kolaydır. Hepsinin ulaşmasını sağlamak değildir. Davetiyeler gönderenin kontrol etmediği kanallardan gider ve spam klasörüne düşen bir mesaj, çiftin gözünde onları görmezden gelen bir davetliden ayırt edilemez.
- Gönderen alan adını düzgün doğrulayın — ürünün tamamı teslimata bağlıyken SPF, DKIM ve DMARC isteğe bağlı değildir.
- Açılma ve tıklamaları davetli bazında izleyin ki çift, tahmin etmek yerine davetiyeyi gerçekten görmemiş olanları görebilsin.
- Her davetiye bağlantısı hesap gerektirmeden çalışsın. Davetli ile RSVP formu arasındaki giriş duvarı yanıt kaybettirir.
- Bazı davetlilerin çifti telefonla arayacağını varsayın. Elle giriş, yönetici paneline sıkıştırılmış bir kolaylık değil birinci sınıf bir yol olmalı.
Uygulamanın yeri
Vowly Event aynı zamanda App Store ve Google Play'de mobil uygulama olarak da var. İşe yarayan ayrım şu: web yüzeyi davetliye, uygulama çifte aittir. Davetliden hiçbir zaman bir şey kurması istenmemeli; onlara bir bağlantı ve bir form yeter. Ürünü aylar boyunca onlarca kez açacak olan çift ise davetli listesinin yaşadığı zengin yüzeyi alır.
Başka bir ekibe ne söylerdik
Önce davetli listesini kurun, davetiye tasarımlarını sonra. Teslimatı bir kez yapılandırdığınız bir özellik değil, metriklere bağlı bir mühendislik problemi olarak ele alın. Ve altyapınızı ortalamaya değil okuma dalgasına göre boyutlandırın — trafik iki saatlik dalgalarla geliyorsa ortalama hiçbir şey ifade etmez.
İlgili yazılar
Benzer bir iş mi yapıyorsunuz?
Burada anlatılan sistemleri biz kuruyor ve işletiyoruz. Planınızı anlatın, size dürüst bir teknik değerlendirme sunalım.