"Saklamasız" çoğu zaman bir pazarlama kelimesidir. Doğru kullanıldığında ise mimari bir kısıtlamadır ve bu türden kısıtlamalar ilginçtir çünkü işi artırmak yerine ortadan kaldırırlar.
Bir işlem botunun sizin adınıza emir vermesi gerekir. Borsalar bunu API anahtarlarıyla mümkün kılar ve API anahtarları yetkiler taşır: okuma, işlem ve çoğu borsada çekim. Yani tasarım sorusu, yetki isteyip istememek değildir. Asıl soru, hangi yetkileri isteyeceğiniz ve istediğinizden fazlasını aldığınızda ne yapacağınızdır.
Önemli Noktalar
- Bir yetkiyi kullanmayacağına söz vermek, o yetkiye hiç sahip olmamaktan daha zayıftır. Çekim yetkisi taşıyan anahtarları kabul edip görmezden gelmek yerine reddediyoruz.
- Reddetmek, güvenmekten daha güçlü bir garantidir çünkü kodumuzun doğru olmasına ya da ekibimizin dürüst kalmasına bağlı değildir.
- Bir bağlantı akışı kullanıcının hesabına yazma yapıyorsa, bu yazma işlemleri kabul kararından önce değil sonra gelmelidir. Aksi halde birine hayır demeye giderken onun ayarlarını değiştirmiş olursunuz.
- Fon tutmamak, koca bir zor problemler sınıfını ortadan kaldırır: saklama defteri yok, mutabakat yok, çekim kuyruğu yok.
- Yerine gelen şey ise daha dar ve daha keskindir: sisteminiz gerçek zamanlı olarak doğru olmak zorundadır çünkü hiçbir şeyi asla geri alamaz.
1. Bir yetkiyi reddetmek, kullanmayacağına söz vermekten iyidir
Akla ilk gelen uygulama, kullanıcılardan okuma ve işlem yetkili bir anahtar istemek ve çekim uç noktalarını hiçbir zaman çağırmamaktır. Sektörün çoğu bunu yapar ve mantıksız da değildir.
Biz daha katı bir şey yapıyoruz. Bir anahtar çekim yetkisi taşıyarak gelirse reddedilir. Kullanıcı, tam olarak ne yapması gerektiğini anlatan bir mesaj görür:
Bu API anahtarında çekim izni açık. Freya hiçbir zaman para çekmez, bu yüzden bu izne sahip anahtarları kabul etmiyoruz. Lütfen yalnızca Okuma ve İşlem izni olan bir anahtar oluşturun.
Aynı kural, desteklediğimiz üç borsanın hepsinde geçerlidir. Bir geçersiz kılma yolu ya da yönetici istisnası yoktur.
İlk bakışta bu, sırf zorluk çıkarmak gibi görünür. Anahtar aslında çalışırdı. Kullanıcı onu oluşturmak için biraz uğraşmıştır. Reddetmek, yeni bir tane yapması için onu borsaya geri göndermek demektir.
Sebep şudur: iki tasarım farklı sözler verir ve fark yalnızca en kötü gününüzde görünür hale gelir.
- "Çekim uç noktalarını asla çağırmayız" ifadesi bizim davranışımıza dair bir iddiadır. Kodumuz doğru olduğu, bağımlılıklarımız temiz kaldığı ve deploy erişimi olan herkes dürüst davrandığı sürece geçerlidir. Bunlar beklenmesi makul şeylerdir ama kullanıcının doğrulayabileceği şeyler değildir.
- "Anahtar çekim yapamaz" ifadesi ise anahtara dair bir iddiadır. Kodumuzun ne yaptığından bağımsız olarak geçerlidir çünkü kuralı borsa uygular ve kullanıcı bunu kendi borsa ayarlarında bizzat teyit edebilir.
İkincisi daha zayıf bir istek ama daha güçlü bir garantidir. Güvenlik özelliği sizin dışınızda biri tarafından uygulanan tasarımları tercih edin, özellikle de kullanıcının sizin tarafınızı denetleyecek bir yolu yoksa.
Pratikte önemli olan daha küçük bir fayda daha var: hata durumunu sesli hale getirir. Fazla yetkili bir anahtar, tam kurulumu yapmakta olan ve sorunu bir dakikada düzeltebilecek bir kullanıcının gözü önünde, bağlantı anında yakalanır. Alternatifinde ise fazla yetkili anahtar orada sorunsuz çalışır durur ve iş işten geçene kadar kimse bir şey öğrenmez.
2. Herhangi bir şeye dokunmadan önce hayır deyin
Başka bir mühendisin en çok akılda tutmasını istediğim ayrıntı budur çünkü yanlış yapması kolaydır ve yanlış yaptığınızda neredeyse görünmez kalır.
Bir borsayı bağlamak yalnızca bir okuma işlemi değildir. Borsaya göre, bir hesabı çalışabilir bir duruma getirmek ona yazma yapmayı gerektirebilir: hesap modunu ayarlamak, pozisyon modunu belirlemek gibi. Bunlar kurulumun parçası olan meşru adımlardır.
Şimdi sıralamayı düşünün. İzin kontrolü bu yazma işlemlerinden sonra yapılırsa, reddedilen bir anahtar yine de iz bırakır. Kullanıcı size bir kimlik bilgisi verdi, siz onun hesabındaki ayarları değiştirdiniz ve sonra ona hayır dediniz. Onun tarafından bakıldığında, borsa yapılandırmasının neden bıraktığından farklı olduğunu açıklayan hiçbir şey yoktur.
Bu yüzden karar kıldığımız kural şu: reddedilen bir kimlik bilgisi, kullanıcının hesabını tam olarak bulduğu gibi bırakmalıdır. Yazma yapan her adım, kabul kararından sonra gelir, asla ondan önce değil. Reddetmeye, yan etki olmadan ulaşılabilmelidir.
Genellenirse bu, başkasının sistemine uygulanan işlemsel (transactional) düşünmeden ibarettir. Üçüncü taraf bir hesaba yapılan yazmayı geri alamazsınız, dolayısıyla tek korumanız sıralamadır. Geri alamıyorsanız, sırayı dikkatle kurun.
Bizi koca bir hata sınıfından kurtaran bir uygulama notu: reddetme, özel bir bayrak yerine geçersiz bir sonuç olarak ifade edilir; böylece bir doğrulama sonucunu tüketen her yol, onun varlığını bilmek zorunda kalmadan bunu ele alır. İki bağlantı akışımız var ve ikisi de aynı reddetmeyi devralır çünkü hiçbirinin bunu sormayı hatırlaması gerekmedi. Bir kuralı, tüm tüketicilerin zaten okuduğu bir tipin içine gömmek, onu belgeleyip en iyisini ummaktan iyidir.
3. Kısıtlamanın ortadan kaldırdıkları
İşte ödünleşimin açıkça lehimize döndüğü yer burası.
Fonlar kullanıcının borsa hesabından asla çıkmaz. Botlar okuma-ve-işlem yetkili anahtarlarla işlem yapar ve bakiye başladığı yerde kalır. Bundan çıkan sonuç, sistemimizde hiç var olmayan uzun bir şeyler listesidir:
- Saklama defteri yok, dolayısıyla dahili bir bakiye ile harici bir bakiye arasında mutabakat da yok
- Çekim kuyruğu yok, onay iş akışı yok, işlem sermayesi üzerinde günlük limitler yok
- Bu sermaye için sıcak ve soğuk cüzdan ayrımı yok, etrafında anahtar yönetimi de yok
- Şirket ortadan kalkarsa kullanıcı fonlarına ne olacağı sorusu yok
Bunların her biri, saklama yapan (custodial) bir üründe koca bir alt sistemdir ve her biri paranın kaybolabileceği bir yerdir. Burada yoklar çünkü onları çözdüğümüzden değil, onları yaratan şeyi hiç üstlenmediğimizden.
Yine de geniş genellemeler yerine kesin konuşmak istiyorum: bu, işlem sermayesi için geçerlidir. Aboneliklerde kullanılan platform bakiyeleri, kendi ele alınış biçimi olan ayrı bir konudur. Saklamasız olma özelliği, işlem yapan parayla ilgilidir ve en çok önem taşıyan da o paradır.
4. Neyi düzeltmediği
Problemleri ortadan kaldıran bir kısıtlama, hataları düzeltmek için kullanacağınız araçları da ortadan kaldırır ve bu konuda dürüst olmakta fayda var.
İşlemler nihaidir. Saklama olduğunda, dahili bir transfer prensipte geri alınabilir. Başkasının borsa hesabında gerçekleşmiş bir emir ise geri alınamaz. Tüm mühendislik ağırlığı, istek indikten sonra mutabakat yapmaktan değil, istek çıkmadan önce doğru olmaya kayar. Bu, kulağa geldiğinden daha zorlu bir disiplindir ve işimizin bu kadar büyük bölümünün doğrulama, hassasiyet ve idempotency (aynı isteğin tekrarı) üzerine olmasının nedeni de budur.
İşlem yetkisi hâlâ gerçek bir yetkidir. Sızdırılmış bir okuma-ve-işlem anahtarı, bir hesabı harici bir adrese boşaltamaz; oysa insanların asıl korktuğu sonuç budur. Ama emir verebilir. Etki alanı sıfır değil, sınırlıdır ve onu sıfır diye tanımlamak dürüstçe olmaz.
Kullanıcının hâlâ yükümlülükleri vardır. Anahtar rotasyonu, anahtarları farklı servislerde tekrar kullanmamak ve aynı hesaba başka nelerin eriştiğini izlemek kullanıcıya aittir. Mimarimiz zararı sınırlar; anahtarı zararsız hale getirmez.
Başka bir ekibe ne söylerdim
- En dar yetkiyi isteyin, sonra onu aldığınızı doğrulayın. Daha azını istemek, daha azını almakla aynı şey değildir.
- Kendi kodunuzun dışında uygulanan garantileri tercih edin, özellikle de kullanıcının size güvenmek zorunda kalmadan kontrol edebileceklerini.
- Reddetmeyi yan etkisiz yapın. Akışınız üçüncü taraf bir hesaba yazma yapıyorsa, yazma yapan her şey kabul kararından sonra gelir.
- Kuralı, tüketicilerin zaten baktığı yere gömün. Paylaşılan bir tipte ifade edilen bir kuralı her çağıranın hatırlaması gerekmez.
Daha büyük mesele şu: "X'i yapmayız" ile "X'i yapamayız" bir tanıtım sayfasında benzer okunur ama bir olay anında tamamen farklıdır. Bir sözü birinci kategoriden ikinciye taşıyabildiğiniz her durumda maliyet genellikle küçüktür ve getiri, tam da diğer her şey ters giderken ortaya çıkar.