Interviu Java arhitect: consistență și sisteme

Un interviu pentru arhitect Java pornește de la un sistem și de la constrângerile lui. Limbajul contează, dar o diagramă cu multe servicii nu demonstrează că datele rămân corecte când apar erori. În acest articol proiectăm un flux de rezervare și urmărim explicit eșecurile.

Ce pregătești la acest nivel

Recapitulează concurența și limitele unui serviciu Java. Continuă cu granițe de module, tranzacții, idempotență, mesaje, observabilitate și evoluția contractelor. Exercițiul de aici este o propunere de arhitectură, nu o descriere a infrastructurii Algo25 și nici o soluție universală.

Începe interviul cu întrebări concrete: câte rezervări avem, ce latență acceptăm, ce nu putem pierde și câți oameni operează sistemul? Separă cifrele primite de ipotezele tale. Dacă estimezi 100 de cereri pe secundă, notează că este o ipoteză și arată ce s-ar schimba la un trafic de zece ori mai mare.

Cerința și invariantul

Proiectăm rezervarea unor locuri la un eveniment. Invariantul principal este: numărul locurilor confirmate nu depășește capacitatea. Emailul de confirmare poate întârzia; rezervarea însă trebuie să rămână vizibilă după ce am confirmat-o utilizatorului.

Identifică operația atomică: verificarea disponibilității și înregistrarea rezervării. Două cereri simultane pentru ultimul loc nu pot fi rezolvate prin două citiri independente urmate de două scrieri. Alegerea exactă între actualizare condiționată, blocare și alt mecanism depinde de baza de date. La interviu trebuie să explici garanția cerută și să verifici că mecanismul ales o oferă.

O primă arhitectură rezonabilă

Pentru o echipă mică, propunem un monolit modular cu module pentru evenimente, rezervări și notificări. Modulul de rezervări deține regulile și accesul la datele sale. Notificările consumă evenimente după confirmarea tranzacției. Putem separa procesul care livrează mesajele fără să împărțim imediat întreaga aplicație în microservicii.

Avantajul este că tranzacția locală rămâne simplă, iar livrarea este mai ușor de operat. Costul este că modulele împart o unitate de livrare și unele resurse. Alegerea trebuie reevaluată când apar cerințe măsurate de scalare independentă, izolare sau ritmuri diferite de livrare, nu doar fiindcă proiectul este scris în Java.

Confirmare și notificare fără pierderea evenimentului

Dacă salvăm rezervarea și apoi trimitem emailul, procesul poate cădea între pași. Dacă trimitem întâi emailul, o tranzacție eșuată poate lăsa un mesaj de confirmare pentru o rezervare inexistentă.

O opțiune este transactional outbox: în aceeași tranzacție salvăm rezervarea și un eveniment într-un tabel outbox. Un proces separat îl livrează ulterior. Livrarea poate produce duplicate, deci consumatorul trebuie să le trateze. Aceste proprietăți sunt explicate în ghidul AWS despre transactional outbox.

Nu promite „exactly once” doar pentru că ai introdus o coadă. În exercițiul nostru, evenimentul are un ID stabil. Păstrăm starea procesării și folosim, unde există, o cheie de idempotență a furnizorului. Dacă furnizorul de email nu oferă deduplicare, trebuie să recunoaștem posibilitatea trimiterii repetate la un eșec între trimitere și marcarea succesului.

Repetarea cererii utilizatorului

Clientul poate retrimite aceeași cerere după o întrerupere a conexiunii. Asociem cheia de idempotență identității și operației, păstrăm amprenta cererii și rezultatul, apoi returnăm același rezultat la repetare. Aceeași cheie cu alt conținut trebuie respinsă, nu tratată ca o rezervare nouă.

Stabilim durata de păstrare a cheilor și o constrângere de unicitate aplicată atomic. Un cache local într-o instanță Java nu rezolvă deduplicarea între mai multe instanțe sau după restart. Dreptul de rezervare se verifică pe server la fiecare operație; existența butonului în interfață nu este autorizare.

Exersează

1. Simulează două cereri pentru ultimul loc. Răspunsul acceptabil are o singură confirmare și o singură respingere, fără capacitate negativă.
2. Oprește mental procesul imediat după commit. Explică de unde reia livrarea notificării și cum detectezi că mesajele s-au acumulat.
3. Scrie o decizie de o pagină: context, variante, alegere, consecințe și criteriu de reevaluare. Include revenirea la versiunea anterioară când modifici schema evenimentului.

Autoevaluare

Ai o explicație solidă dacă poți urmări fiecare stare intermediară, poți numi proprietarul datelor și poți justifica costul operațional. Urmărește rata erorilor, latența rezervării și vârsta celui mai vechi eveniment nelivrat. Un sistem cu endpoint rapid, dar notificări blocate ore întregi, nu este sănătos doar pentru că răspunde cu succes.

Întrebări frecvente

Arhitect Java înseamnă obligatoriu microservicii?

Nu. Responsabilitatea este alegerea granițelor și garanțiilor potrivite. Numărul serviciilor nu măsoară calitatea arhitecturii.

Outbox rezolvă și suprarezervarea?

Nu. Invariantul rezervării trebuie protejat în tranzacția de business. Outbox leagă schimbarea datelor de intenția de publicare a unui eveniment.

Pot deduplica numai în browser?

Nu. Cererile pot veni din mai multe dispozitive, iar browserul poate pierde starea. Protecția autoritativă trebuie să fie pe server.

Când extrag un modul într-un serviciu?

Când ai un motiv concret și măsurabil, plus capacitatea de a opera noile granițe, eșecuri și contracte de comunicare.

Ce prezint dacă nu cunosc volumul de trafic?

Cere clarificări, apoi declară ipoteze. O estimare explicată este mai utilă decât cifre prezentate ca fapte fără sursă.

Surse și continuare

Sursa tehnică despre outbox a fost consultată la 12 octombrie 2026. Compară acest exercițiu cu React arhitect: granițe și randare pentru responsabilitățile interfeței.