Sună excelent într-o prezentare, dar datoria arhitecturală te poate copleși înainte să ajungi la product-market fit.
Există o problemă tot mai frecventă în dezvoltarea software pentru startup-uri. Echipe cu trei programatori și niciun client plătitor își proiectează sistemele ca și cum ar fi Netflix. Împart domeniul principal în cinci microservicii, introduc Kafka pentru fluxuri de evenimente și consumă 40% din sprinturi doar pentru gestionarea configurărilor Kubernetes.
Noi am încetat să lucrăm astfel. Iar clienții noștri livrează de două ori mai repede.
Capcana microserviciilor
Microserviciile rezolvă în primul rând o problemă organizațională, nu neapărat una tehnică. Când ai 500 de ingineri, ele ajută echipele să lanseze independent fără să se blocheze reciproc.
Când ai un startup care încă își caută product-market fit-ul, cea mai mare amenințare nu este scalarea. Este timpul.
1. Costul serializării
De fiecare dată când Serviciul A comunică cu Serviciul B, treci o graniță de rețea. Trebuie să serializezi date, să gestionezi latența, să implementezi reîncercări și să tratezi mesajele eșuate. Ceea ce într-un monolit era un simplu apel const user = await getUser(id) devine o problemă de sisteme distribuite.
2. Coșmarul lansărilor
În loc să lansezi un singur container, orchestrezi o flotă. Ai nevoie de urmărire distribuită doar pentru a descoperi de ce resetarea parolei unui utilizator a eșuat.
Întoarcerea monolitului bine construit
La Diloxy, pentru sistemele cu mai puțin de 100.000 de utilizatori activi zilnic, am revenit complet la monolituri bine structurate.
Folosim o arhitectură Node.js puternic modularizată.
// O arhitectură simplă, clară și autonomă
import { PaymentService } from './modules/payments';
import { UserService } from './modules/users';
export async function processCheckout(userId, amount) {
const user = await UserService.findById(userId);
if (!user.isActive) throw new Error("Account inactive");
return await PaymentService.charge(user.stripeId, amount);
}
Fără salturi prin rețea. Tipuri sigure pe întregul flux. O singură suită de teste care poate rula local, cap-coadă, pe laptopul unui dezvoltator, fără Docker Compose sau un mediu cloud de staging.
Când scalăm?
Scalăm atunci când apare o nevoie reală. Dacă PaymentService începe să consume 80% din procesor din cauza generării intensive de PDF-uri, atunci îl separăm într-un worker cu o coadă proprie. Îl extragem din necesitate, nu din optimizare prematură.
Dacă ai o companie cu o arhitectură uriașă de microservicii, atât de interconectată încât sufocă ritmul lansărilor, este posibil să fi mers prea departe.
Nu mai anticipa scalarea. Optimizează viteza de execuție.