Dincolo de monoliți
și microservicii.

01 / Alegerea arhitecturii

Monoliții și microserviciile rezolvă probleme diferite.

Un monolit împachetează o aplicație ca o singură unitate implementabilă. Poate fi modular, testat atent și replicat în spatele unui load balancer. Atracția lui este practică: apeluri locale, depanare directă și mai puține componente. Limitările apar adesea în jurul lansărilor comune, al limitelor de responsabilitate sau al nevoilor inegale de resurse.

Microserviciile împart o aplicație în servicii implementabile independent. Sunt utile atunci când domeniile și echipele au nevoie de propriile cicluri de lansare, politici de scalare sau limite operaționale. Această independență vine cu muncă: apeluri prin rețea, contracte versionate, observabilitate, gestionarea eșecurilor și, adesea, consistența între depozite de date separate.

Niciuna dintre variante nu este automat mai rapidă sau mai scalabilă. Un monolit bine proiectat poate servi o sarcină de lucru mare. Un sistem de microservicii prost partiționat își poate distribui blocajele și le poate face mai greu de observat.

Distincția contează, pentru că distribuirea implementării și modularitatea de business sunt decizii separate. Puteți avea module fără servicii separate; puteți avea multe servere fără să fragmentați modelul logic al aplicației.

02 / Un singur model logic

Baza de date și backendul, mai aproape una de cealaltă.

Cygnus este fundația planificată de limbaj, bază de date și backend a NatusAI. Designul reunește logica de aplicație tipizată, datele persistente și funcțiile expuse într-un singur mediu coerent. În loc să întrețină o mapare separată la fiecare limită, dezvoltatorii lucrează cu obiecte conectate și cu funcțiile care acționează asupra lor.

Acest lucru este relevant mai ales pentru un digital twin sau pentru o aplicație operațională. O navă, o clădire sau un activ industrial are identitate, relații, locație, măsurători, documente și un istoric. Împărțirea fiecărei perspective într-un sistem fără legătură cu celelalte înseamnă reconstruirea unor conexiuni care există deja în companie.

Un model unificat urmărește să păstreze aceste conexiuni. De asemenea, oferă runtime-ului mai multe informații despre date, interogări și execuție, informații care pot sprijini viitoarele decizii de plasare și coordonare.

Un singur model pentru aplicație.
Mai multe opțiuni pentru locul în care rulează.

Acesta este un principiu de design, nu o promisiune că orice sarcină de lucru scalează transparent. Cheile de partiționare, tiparele de interogare, limitele tranzacțiilor și latența influențează în continuare modul în care trebuie construită o aplicație.

03 / Patru moduri de a crește

Scalați cererile și datele ca nevoi distincte.

„Trebuie să scalăm” poate însemna mai multe cereri simultane, un set de date mai mare, o disponibilitate mai bună sau toate trei. Replicarea și shardingul abordează părți diferite ale acestei probleme. Vizualizarea interactivă de mai jos ilustrează direcția de design distribuit Cygnus; nu este un cluster live sau o funcționalitate de implementare lansată.

Porniți de la un singur nod

Profilul planificat v1 pornește de la un singur server. Codul aplicației și datele stau împreună, ceea ce face prima implementare accesibilă. Backupurile, recuperarea, permisiunile și limitele de resurse rămân parte dintr-o operare responsabilă.

Replicați pentru redundanță și capacitate de procesare a cererilor

În viitorul model distribuit, mai multe noduri ar putea avea același cod și o copie completă a setului de date. Astfel pot exista mai multe locuri care servesc cererile potrivite, iar sistemul poate tolera căderea unor noduri. Rezultatul depinde de rutare, de întârzierea replicării, de garanțiile de consistență și de operațiile care pot rula pe fiecare replică.

Partiționați (sharding) pentru capacitatea de date

Când setul de date depășește un server, adăugarea de copii complete nu rezolvă constrângerea de stocare. Shardingul împarte datele între noduri. O sarcină de lucru poate fi partiționată după geografie, interval de timp sau interval de chei. Interogările care traversează aceste partiții au nevoie de rutare și, uneori, de execuție distribuită.

O ilustrare simplă a capacității: 30 TB de date logice necesită cel puțin opt servere a câte 4 TB fiecare, înainte de replici, indexuri, rezervă operațională sau alt overhead. Este aritmetică, nu o măsurătoare a capacității Cygnus.

Combinați cele două

Fiecare shard poate avea propriile replici. Shardurile oferă capacitatea de date agregată; replicile adaugă redundanță și posibilități de a servi cereri. Această topologie combinată este adesea ceea ce își imaginează oamenii când se gândesc la o bază de date distribuită pe o flotă de servere.

Creștere și restrângere în funcție de cerere

Direcția pe termen lung este automatizarea acestor alegeri pe baza politicilor de sarcină: adăugarea de capacitate când cererea crește, mutarea execuției împreună cu datele de care are nevoie și eliberarea capacității când cererea scade. Scopul este păstrarea modelului logic al aplicației pe măsură ce plasarea se schimbă.

Restrângerea trebuie mai întâi să golească munca în curs și să mute sau să păstreze în siguranță copiile de date necesare. Programarea, reechilibrarea, consistența și recuperarea au nevoie de reguli explicite și de calificare. Scalarea automată pe orizontală, în sus și în jos, este un obiectiv viitor de design pentru cluster, în afara v1 planificate pe un singur server.

04 / Responsabilitatea runtime-ului

Mutați coordonarea în platformă.

Experiența gândită pentru Cygnus păstrează un singur cod de aplicație și o singură bază de date logică pe măsură ce implementarea evoluează. Distribuirea gestionată de runtime ar prelua plasarea, rutarea, replicarea și mecanica de coordonare a nodurilor participante.

Această mecanică nu dispare. Rețelele introduc latență și partiționări. Actualizările au nevoie de reguli de consistență. Tranzacțiile care se întind pe mai multe sharduri au nevoie de un protocol definit. Recuperarea trebuie să știe ce a fost confirmat (commit), iar reechilibrarea trebuie să evite pierderea responsabilității asupra datelor în timp ce acestea se mută.

Oportunitatea este ca aceste responsabilități să fie implementate o singură dată în platformă, cu contracte și instrumente de operare explicite, în loc ca fiecare aplicație să își construiască propria versiune. Aplicația are în continuare nevoie de limite potrivite pentru sarcina ei de lucru.

05 / Datele în timp

Un model conectat are nevoie de memorie.

Multe întrebări de business includ o dimensiune temporală, chiar dacă nimeni nu o spune cu voce tare. Unde era acest activ înaintea unui incident? Ce organizație îl controla atunci? Ce știa sistemul când a făcut acea recomandare?

Designul Cygnus conectează relațiile de graf, datele geospațiale, vectorii, tripleții, seriile temporale și căutarea full-text în aceeași fundație logică. Acestea sunt moduri de a explora un subiect, nu definiții separate a ceea ce este acel subiect.

Istoric pentru date și proveniență pentru AI

Datele temporale pot descrie cum se schimbă un activ, citirile sau relațiile lui. Un răspuns AI istoric necesită mai mult. El depinde și de documentele-sursă, embeddings, configurația de regăsire, versiunea modelului și promptul folosite pentru a-l produce.

Păstrarea istoricului datelor nu păstrează automat fiecare index vectorial și nici nu reproduce un răspuns trecut al modelului. Un design util leagă aceste versiuni și le înregistrează deliberat proveniența, astfel încât un răspuns să poată trimite înapoi la dovezile și contextul care l-au susținut.

O singură fundație pentru aplicații și instrumente

Capabilitățile planificate de MCP nativ și chat oferă modalități de a expune funcțiile permise și de a interoga cunoașterea conectată. Un instrument sau o interfață conversațională ar trebui să lucreze pe același model și cu aceeași politică de acces ca aplicația. O interogare istorică poate întreba atunci despre un moment ales, explicând ce dovezi și ce configurație AI sunt disponibile pentru acel răspuns.

Aici un backend unificat devine mai mult decât o poveste despre o implementare mai simplă: poate oferi o fundație comună pentru datele operaționale, istoricul companiei și munca asistată de AI.

06 / Alegerea limitelor

Păstrați arhitectura aliniată cu munca.

Microserviciile rămân utile atunci când echipe independente, limite de securitate distincte sau cerințe de operare diferite le justifică. Un monolit modular rămâne util atunci când o implementare comună menține echipa productivă. Direcția Cygnus adaugă o altă opțiune: un model unificat de aplicație și date, cu distribuirea gestionată mai adânc, în runtime.

Alegerea potrivită pornește de la sarcina de lucru. Ce cereri domină? Cât de repede trebuie să devină vizibile actualizările? Ce date trebuie să stea împreună? Ce se întâmplă la o cădere de rețea? Ce responsabilități au nevoie de un proprietar independent?

Ambiția noastră este ca dezvoltatorii să petreacă mai mult timp cu aceste decizii importante și mai puțin timp reconstruind conexiunile dintre instrumentele lor. Porniți de la un model coerent. Păstrați intacte relațiile de business. Extindeți implementarea fizică atunci când sarcina de lucru și platforma sunt pregătite.