Schimbare majoră la BNR: eliminarea BGN și impactul în convertoare
Context
Orice produs care consumă date externe trebuie să accepte un adevăr simplu: sursa se poate schimba, uneori fără o perioadă lungă de tranziție. Pentru convertoarele valutare, aceste schimbări apar uneori ca modificări incompatibile în structură sau în setul de monede publicate. În cazul discutat aici, eliminarea BGN din fluxul BNR a avut impact imediat asupra aplicațiilor care presupuneau o listă fixă de monede, fără validare de contract.
Pe 24 aprilie 2026, lecția principală nu este doar „o monedă a dispărut”, ci și faptul că ipotezele scrise rigid în cod sunt fragile. Dacă integrarea tratează lista de monede ca adevăr imuabil, schimbarea produce erori în lanț: liste derulante cu opțiuni invalide, conversii imposibile, pagini de perechi nefuncționale, teste care eșuează fără explicație clară și un val inutil de solicitări de suport.
În Convertesc.ro, abordarea robustă este să decuplezi contractul intern de formatul brut prin validare, listă de monede suportate explicit și comportament predictibil atunci când o monedă nu mai există în datele curente. Acest model nu elimină schimbarea incompatibilă, dar îi reduce mult impactul operațional.
Cum funcționează
Tratamentul corect pentru o eliminare de simbol are trei componente. Prima: detectare. Fluxul de import trebuie să poată semnala că un simbol a dispărut față de setul așteptat. A doua: izolare. Interfața și API-ul nu trebuie să se bazeze pe presupunerea că simbolul există în fiecare zi; ele trebuie să lucreze cu lista suportată curentă și cu reguli clare de invalidare. A treia: comunicare. Schimbarea trebuie documentată clar în jurnalul intern și, dacă e cazul, în cel public.
În practică, asta înseamnă că selecțiile de monedă din interfață nu ar trebui generate dintr-un cache vechi fără revalidare. Pe API, endpoint-urile care acceptă base și symbols trebuie să răspundă coerent la simboluri eliminate, cu cod și mesaj de eroare stabile. În plus, perechile publice trebuie definite explicit astfel încât eliminarea unui simbol să nu rupă rute necontrolat.
Această disciplină completează bine practicile din articolul despre monitorizare și verificări de stare și articolul despre zilele fără curs: toate tratează schimbarea datelor ca pe un eveniment normal, care trebuie absorbit elegant.
Exemplu practic
Listă minimă de verificare pentru absorbția unei schimbări de tip „simbol eliminat”:
- Rulezi importul și compari setul de simboluri cu ziua precedentă.
- Marchezi diferențele într-un log operațional.
- Actualizezi lista de monede suportate în aplicație.
- Rulezi testele pe rute perechi și endpoint-uri API.
- Publici notă de schimbare cu dată explicită.
Exemplu de validare API în aplicația care consumă datele:
curl "https://convertesc.ro/api/v1/latest?base=RON&symbols=BGN"
În loc de un comportament nedefinit, aplicația ar trebui să primească o eroare de validare clară, apoi să scoată simbolul din opțiuni sau să afișeze un mesaj explicit. Aceeași regulă se aplică și în interfață: mai bine un mesaj clar „simbol indisponibil” decât o conversie aparentă bazată pe date vechi.
Dacă produsul tău are și pagini pe perechi, verifică imediat whitelist-ul public de rute și sitemap-ul, astfel încât să nu expui linkuri moarte. În Convertesc.ro, această practică păstrează experiența curată chiar când sursa evoluează.
Greșeli frecvente
Prima greșeală este presupunerea că „ce a fost ieri va fi mereu”. Această ipoteză intră în cod sub formă de constante neschimbate și validări incomplete. Când sursa se modifică, aplicația nu are unde să absoarbă schimbarea.
A doua greșeală este propagarea simbolului eliminat prin cache-uri secundare. Chiar dacă partea de server știe noua realitate, interfața sau un serviciu intermediar poate continua să afișeze opțiunea invalidă. Soluția este o invalidare controlată și o sursă unică de adevăr pentru lista curentă.
A treia greșeală este lipsa testelor contractuale pe setul de simboluri. Multe suite verifică doar formulele de calcul, nu și validitatea simbolurilor de intrare. Când apare o schimbare incompatibilă, testele trec parțial și incidentul ajunge în producție.
A patra greșeală este comunicarea incompletă. Dacă schimbarea nu este explicată în limbaj clar, utilizatorii interpretează lipsa monedei ca defect local. O notă concisă cu data exactă, impactul și soluția reduce semnificativ fricțiunea.
A cincea greșeală este tratarea incidentului ca excepție irepetabilă. În realitate, schimbările de contract se pot repeta. Cea mai bună reacție este să extragi reguli permanente de reziliență: detectare timpurie, validare strictă, monitorizare și comunicare.
Concluzie
Eliminarea BGN este un exemplu util de schimbare incompatibilă reală într-un domeniu în care mulți presupun stabilitate totală. Lecția principală pentru echipele tehnice este să trateze sursa externă ca pe un sistem viu, nu ca pe un fișier static. Cu detectare, izolare și comunicare, impactul unei astfel de schimbări poate fi ținut sub control.
Pentru Convertesc.ro, această abordare susține obiectivul de fiabilitate: conversii corecte, comportament predictibil și transparență când apar schimbări externe. Dacă vrei să întărești implementarea, combină acest model cu practicile din articolul despre cursul curent și cursul istoric și articolul despre monitorizare și verificări de stare.