İhtiyaçlarınıza göre uyarlanmış kişiselleştirilmiş bir FinMV teklifi için bizimle iletişime geçin.
Şirketinizin teknik direktörü, bir finansal platformun lansmanını planlarken bir proje mimarisi seçeneği seçmek zorunda kalacaktır. Kullanabileceği mimari seçenekler nelerdir ve hangisini seçmek daha iyidir?
Yeni bir yatırım platformunun tek bir ekibi, tek bir dağıtımı ve tek bir veritabanı vardır. Bu aşamada dağıtık bir sistemin maliyeti tamamen ek yüke gider: bir fonksiyon çağrısının yeteceği yerde ağ çağrıları, bir işlemin yeteceği yerde nihai tutarlılık ve kimsenin kadrolu olmadığı bir işletim yükü.
Bu yüzden varsayılan uygulama modülerdir: katılım, teklifler, yatırımlar, ödemeler, belgeler, hizmet ve raporlama, tek bir dağıtılabilir sistem içinde açık sınırların arkasında yaşar. Onu modüler yapan klasör yapısı değil, her modülün bir sözleşmesi, kendi verisi ve kendi testleri olmasıdır.
Bir modül, somut bir sebep olduğunda ayrı bir hizmete dönüşür ve bu sebepler moda değil iş gerekçeleridir:
Sınırlar ve sözleşmeler zaten var olduğundan, ayırma işlemi bir yeniden yazma değil, planlı bir operasyondur. Bu şekilde inşa etmenin anlamı budur: seçenek açık ve ucuz kalır.
Bir kullanıcıyı bloke etmemesi gereken iş — mutabakat, belge oluşturma, sağlayıcı geri çağrıları, raporlama — kuyruklar üzerinden yürür. RabbitMQ veya Kafka gibi mesaj aracıları, verim veya entegrasyon topolojisi bunu haklı çıkardığında devreye girer, varsayılan olarak değil. PostgreSQL kayıt sistemi olarak kalır; Redis, gerçekten hızlı önbellekleme veya koordinasyon gerektiğinde kullanılır.
Ne bir tek parça (monolit) satıyoruz ne de mikro hizmetler satıyoruz. İkisi de henüz sorulmamış sorulara verilen yanıtlardır. Platformu ciddi göstermek için dağıtık bir sistem de kurmuyoruz — mimari tiyatro işletmesi pahalı ve devretmesi zordur.
Mimariniz ölçeğinize, düzenleyici yükümlülüklerinize, entegrasyonlarınıza ve onu işletecek ekibin büyüklüğüne göre seçilir — ve bunlar değiştikçe değişebilecek şekilde tasarlanır.
