tek mantıklı yol en son butona tıkladıgında tüm veriyi analiz etmem.
birde adres gibi basit şeyleri session etmeni çok tavsiye etmiyorum. cookie daha mantıklı gerekirse şifrelersin.
her session sunucu belleginde bir byte a eş gelecek
bu projenin oldugu siteyi yarın 100.000 kişi ziyaret ederse her birinin adresi bellege yerleşecek yani ram ve zaman kaybı

Aslında işlemler aynı sayfada gerçwkleşiyor.
Tabpanel var birinde adres bilgileri teslimat ve fatura. Diğer tab da ödeme bilgileri.
Sayfa açılınca yada yeni adres eklenirken adres varsa yada ilkkez eklendiyse session a değer atsam butona tıkladığında sessionu kontrol etsem olmaz mı sonuçta session sunucuda.

kullanıcı adres seçince devam et gübi bir butonu aktif etmekten bahsediyorsun sanırım.
diyorsun ki: kullanıcı kendisi dom'u manipule edip kendisi bir adres eklerse ve o adresi seçerse buton yine aktif olacak. o yüzden adres seçildiğinde adresin varlığını kontrol etmek için sunucuma istek atayım ve dönen sonuca göre butonu aktif edeyim.
doğru anladıysam,
böyle bir isteği atmana gerek yok. kullanıcı senin sunucuya istek atacağın fonksiyonu da manipule edebilir. veya sunucuya istek atmana fırsat vermeden butona kendisi de active class'ı verebilir veya disabled prop'unu false yapabilir. hatta kullanıcının bu işlemi yapması için web sitene girmesine bile gerek yok. sunucuna postman gibi bir program üzerinden doğrudan post isteği de atabilir. yani kötü niyetli kullanıcıyı o aşamada durduramazsın.
o yüzden sunucuya ek yük bibdirmene ve performans kaybı yaşamana gerek yok.
senin yapman gereken sayfada performansa odaklanmak olmalı. kullanıcı devam et butonuna bastıktan sonra sunucuya istek atmalısın. sunucu isteği karşıladığında önce adres seçilmiş mi diye bakar. sonra adresin varlığını kontrol eder. bu aşamalarda sorun varsa sonraki sayfayı göstermeden direkt hata sayfasına redirect edilir veya aynı sayfaya bir hata mesajıyla redirect edilir.
eğer sunucu kontrolünde bir sorun yoksa kullanıcı doğru sayfaya (sonraki aşamaya) benzersiz bir token ile redirect edilir. bu token içinde benzersizliği sağlayan bir şifre haricinde şifrelenmiş halde adres bilgisi de bulunur.
sonraki aşamada da sunucu önce token kontrolü yapar. token doğru değilse bu sayfaya kötü niyetli bir istek atılmış demektir. sunucu sayfayı göstermeden kullanıcıyı direkt hata sayfasına redirect eder. token doğruysa içindeki adres bilgisi okunur. böylece yeni sayfada adres bilgileri için yeniden veritabanına sorgu da atılmamış olur. veritabanına ne kadar az istek atılırsa o kadar iyi...
her bir devam et butonu olan sayfanda bu yöntemle ilerlersen hem front end'de performanstan ödün vermemiş olursun, hem veriyi token'larla taşıdığın için veritabanına yük bindirmemiş olursun, hem de kimse senin şifreleme anahtarını bilemeyeceği için istemediğin bir sayfaya erişemez.

frontend kısmında hangi yöntemi kullanırsan kullan, meraklı kullanıcılar mutlaka bir şeyleri değiştirirler. Onun için her zaman ön tarafta yaptığın tüm işlemleri backend tarafına istekte bulunduğunda tekrar kontrol etmelisin. Çok uzun bir iş gibi görünse de olması gereken bu.