Финален SaaS Blueprint

Како Evento се претвора од идеја и збир на функционалности во целосно дефиниран, сигурен, мерлив и одржлив SaaS производ

1. Целта на финалниот Blueprint

Во претходните осумнаесет глави го следевме Evento низ целиот животен циклус на еден сериозен SaaS производ.

Не започнавме со избор на програмски јазик, framework или cloud provider.

Започнавме со прашањето:

Од таму постепено ја изградивме целата патека:

Оваа глава не воведува нова технологија.

Не додава уште еден framework, уште една архитектонска шема или уште еден инфраструктурен слој.

Нејзината задача е поважна.

Таа треба да покаже како сите претходни одлуки се поврзуваат во една конзистентна целина.

Тоа е финалниот системски blueprint на Evento.

Во него мора да можеме да ја следиме врската:

Ако не можеме да ја следиме оваа врска, тогаш имаме збир од документи и компоненти, но не и навистина дизајниран систем.

Финалниот blueprint затоа служи како:

• архитектонска мапа;
• продуктна референца;
• оперативен модел;
• инженерска меморија;
• основа за идно скалирање;
• основа за onboarding на нови членови на тимот;
• основа за security и compliance review;
• основа за комуникација со инвеститори, партнери и enterprise клиенти.

Вредноста на овој blueprint не е во тоа Evento засекогаш да остане ист.

Напротив.

Добриот blueprint овозможува системот да се менува без да ја изгуби логиката врз која е изграден.

2. Evento во една реченица

Секој сложен производ треба да може јасно да се објасни во една реченица.

Ако за да објасниме што прави производот ни се потребни десет минути, најчесто или scope-от е премногу широк или вредносната понуда не е доволно јасна.

Evento го дефинираме вака:

Оваа дефиниција е доволно широка за да ја опише визијата, но доволно конкретна за да постави архитектонски граници.

Од неа веднаш можеме да извлечеме неколку фундаментални својства:

• Evento е SaaS, а не еднократна custom апликација;
• системот е multi-tenant;
• организациите се примарни клиенти;
• настаните се основниот деловен ентитет;
• регистрацијата е критичен кориснички тек;
• плаќањата се финансиски чувствителен домен;
• билетите и check-in се operationally critical;
• комуникацијата е дел од производот, не надворешен додаток;
• аналитиката мора да обезбеди мерлива деловна вредност;
• AI е контролирана capability, а не автономен source of truth.

Една добра product definition не служи само за маркетинг.

Таа е првиот архитектонски филтер.

Кога ќе се појави нова идеја, можеме да прашаме:

3. Клучниот деловен проблем

Evento постои затоа што реалното управување со настани многу често е составено од рачни и меѓусебно неповрзани процеси.

Пред Evento, еден организатор може да користи:

• Excel или Google Sheets за список на учесници;
• Google Forms за регистрација;
• email за комуникација;
• банкарски изводи за рачна проверка на уплати;
• PDF или рачно подготвени билети;
• хартиени листи за check-in;
• посебни алатки за newsletter;
• посебна алатка за analytics;
• рачно подготвени извештаи;
• повеќе различни spreadsheets за финансии и attendance.

Ниту една од овие алатки сама по себе не мора да биде лоша.

Проблемот настанува кога критичниот деловен процес е распарчен меѓу нив.

Секоја рачна транзиција создава ризик.

Последиците може да бидат:

• дупли регистрации;
• изгубени регистрации;
• погрешно евидентирани плаќања;
• испратен билет на погрешен корисник;
• неусогласени списоци;
• долг процес на check-in;
• недоволна финансиска видливост;
• неможност за точна аналитика;
• голем административен товар;
• зависност од неколку луѓе што „знаат како функционира Excel-от“.

Evento не продава само software features.

Evento продава подобар деловен процес.

Вредноста што ја создава е:

• помалку рачна администрација;
• помалку човечки грешки;
• побрза регистрација;
• побрза и попрецизна наплата;
• побрз check-in;
• подобро искуство за учесниците;
• подобра контрола за организаторите;
• подобра финансиска и оперативна видливост;
• мерливи резултати.

4. Вредносна понуда на производот

Вредносната понуда на Evento не е идентична за секој тип корисник.

Истиот систем создава различна вредност за организаторот, учесникот, оперативниот персонал и самата организација.

За организаторот

Evento овозможува организаторот од една платформа да:

• креира и конфигурира настан;
• управува со ticket types и капацитет;
• следи регистрации;
• управува со waiting list;
• прифаќа плаќања;
• испраќа автоматски трансакциски пораки;
• издава дигитални билети;
• спроведува QR check-in;
• следи приход, attendance и conversion;
• користи контролирана AI асистенција;
• работи со повеќе членови на тимот и различни permissions.

За учесникот

Учесникот добива едноставен и предвидлив тек:

Вредноста е во тоа процесот да биде:

• брз;
• јасен;
• безбеден;
• mobile-friendly;
• без непотребни чекори;
• со јасна потврда за секоја критична операција.

За организацијата

На организациско ниво, Evento обезбедува:

• централизирано управување со повеќе настани;
• повеќе тимови и корисници;
• role-based permissions;
• финансиска видливост;
• audit trail;
• стандардизирани процеси;
• enterprise security controls;
• analytics;
• scalable operating model.

За оперативниот персонал

Check-in staff и support тимовите добиваат:

• јасни operational interfaces;
• минимален потребен пристап;
• брзо пребарување;
• QR validation;
• контролирани override операции;
• audit на чувствителните активности.

5. Финален MVP Scope

Финалниот MVP на Evento не е најмалиот можен технички производ.

Тој е најмалиот комплетен систем што може реално да води настан од креирање до регистрација, плаќање, билет и check-in.

Вклучено во MVP

• регистрација и најава на корисници;
• потврда на email адреса;
• organizations;
• memberships;
• roles и permissions;
• event management;
• public event pages;
• ticket types;
• capacity management;
• registration;
• waiting list;
• payment processing;
• orders;
• QR tickets;
• online check-in;
• transactional email;
• organizer dashboard;
• basic analytics;
• AI event description;
• audit logs;
• SaaS subscriptions;
• CI/CD;
• monitoring и observability;
• backup и recovery fundamentals.

Намерно одложено

• native mobile applications;
• live streaming;
• speaker marketplace;
• целосен CRM;
• white-label infrastructure;
• complex recommendation engine;
• active-active multi-region;
• напреден marketplace payout engine;
• автономни AI agents;
• целосен marketing automation suite;
• social networking capabilities.

6. Зошто Scope дисциплината беше критична

Една од најголемите опасности за Evento никогаш не беше дали PostgreSQL ќе може да обработи доволно queries или дали frontend framework-от ќе биде доволно брз.

Најголемата опасност беше продуктна:

Evento лесно можеше да стане пет различни производи во еден.

На пример:

• CRM;
• accounting system;
• marketing automation platform;
• video platform;
• social network;
• marketplace;
• mobile ecosystem;
• AI productivity suite.

Секоја од овие насоки може сама по себе да изгледа логично.

Но секоја нова capability носи:

• повеќе развој;
• повеќе UI;
• повеќе domain rules;
• повеќе authorization;
• повеќе тестирање;
• повеќе документација;
• повеќе support;
• повеќе security surface;
• повеќе operational complexity;
• повисоки infrastructure трошоци;
• подолго време до market validation.

Затоа scope discipline не е само project-management техника.

Тоа е продуктна и архитектонска контрола на ризик.

Scope Decision Model

Секоја нова функција може да се оцени преку неколку прашања:

7. Финална архитектонска слика

Финалната архитектура на Evento ја претставува целата платформа како повеќе јасно одделени слоеви.

Овој дијаграм е намерно едноставен.

Неговата цел не е да прикаже секоја класа, endpoint или database table.

Целта е секој што го чита да може веднаш да разбере:

• кои се главните корисници;
• каде се наоѓа user interface;
• каде се спроведува API контрола;
• кои се главните domain модули;
• која инфраструктура ја поддржува платформата;
• кои external providers постојат;
• кои operational capabilities се задолжителни.

8. Зошто Modular Monolith беше правилен избор

Evento започнува како Modular Monolith.

Ова не е компромис затоа што „немаме време за microservices“.

Тоа е свесна архитектонска одлука.

Причините се:

• тимот во почетната фаза е релативно мал;
• доменот сè уште еволуира;
• module boundaries треба прво реално да се докажат;
• deployment треба да остане едноставен;
• debugging треба да биде брз;
• distributed transactions не се оправдани;
• operational overhead треба да биде низок;
• инфраструктурните трошоци треба да останат контролирани;
• брзината на product iteration е важна конкурентска предност.

Microservices од првиот ден би донеле:

• повеќе deployment units;
• повеќе repositories или посложен monorepo management;
• network failure modes;
• service discovery;
• distributed tracing;
• contract versioning;
• data consistency проблеми;
• повеќе queue и messaging infrastructure;
• покомплексна локална development средина;
• посложени production incidents;
• повисок оперативен трошок.

Затоа одлуката никогаш не беше:

Одлуката е:

Modular Monolith не значи една огромна неструктурирана апликација.

Напротив.

Секој модул мора да има:

• јасна одговорност;
• сопствени domain rules;
• контролирани dependencies;
• сопствен application layer;
• сопствени contracts;
• сопствени tests;
• контролирана комуникација со другите модули.

Ако овие граници се одржат чисти, дел од модулите подоцна може да се издвојат во посебни сервиси без повторно дизајнирање на целиот систем.

9. Граници што мора да останат чисти

Без разлика дали Evento ќе остане Modular Monolith или дел од модулите подоцна ќе се издвојат како независни сервиси, архитектонските граници мора да останат јасни.

Најголемите системски проблеми ретко започнуваат затоа што постои погрешен framework.

Почесто започнуваат кога еден модул постепено почнува да презема одговорности што не му припаѓаат.

На пример:

• Identity не управува со Payments.
• Payments не менува директно Ticketing tables.
• Events не испраќа email директно.
• AI не ја контролира основната деловна логика.
• Frontend не одлучува за authorization.
• Analytics не ја користи трансакциската база без контролирани ограничувања.
• Support access не значи неограничен production access.

Овие правила на прв поглед изгледаат едноставно, но токму тие ја одредуваат способноста на системот да еволуира.

Не дозволувај директно навлегување во туѓ домен

Ако Payments треба да иницира издавање билет, тој не треба директно да запише запис во tickets табелата.

Правилниот flow е:

Така Payments знае дека треба да објави што се случило, но не знае како Ticketing ја имплементира својата внатрешна логика.

Provider payload не е Domain Model

Надворешен payment, email или AI provider има сопствен формат, терминологија и lifecycle.

Evento не треба да дозволи тој модел директно да стане внатрешен domain model.

Ако утре provider-от се промени, доменот не треба да се редизајнира.

Frontend не е Security Boundary

Frontend може да сокрие копче, route или форма.

Но тоа не е authorization.

Секој чувствителен use case мора повторно да биде проверен на server side.

AI не е Business Authority

AI може да предложи:

• опис на настан;
• резиме на feedback;
• предлог за email;
• аналитичка интерпретација;
• класификација.

Но не треба автономно да:

• одобрува refund;
• менува organizer balance;
• менува permissions;
• брише корисници;
• објавува campaign без governance;
• ја менува финансиската вистина.

Analytics не смее да го загрози Transactional Path

Аналитиката е важна, но registration и payment flow се поважни.

Затоа со растот analytics мора да има:

• read models;
• replicas;
• посебен analytics store;
• query limits;
• workload isolation.

Support Access има сопствена граница

Support тимот не треба да добива broad administrative access само затоа што треба да му помогне на клиент.

Подобар модел е:

• scoped support actions;
• masked data;
• impersonation со audit;
• time-limited access;
• explicit approval за чувствителни случаи.

10. Регистар на ограничени доменски контексти

Evento го дели системот на ограничени доменски контексти (Bounded Contexts) со јасна одговорност и сопственик на податоците.

Регистарот не е само документација.

Тој е договор за тоа:

• кој модул донесува кои одлуки;
• кој е сопственик на податокот;
• кој смее да го менува;
• како другите модули комуницираат со него;
• каде се поставува authorization;
• каде се поставуваат business invariants.

Context Map

Покрај самиот регистар, важно е да се знае и како контекстите зависат еден од друг.

Овој приказ не значи дека секој контекст директно го повикува следниот.

Тој ја покажува деловната зависност.

Контекстите не треба да се преклопуваат

Ако два модула имаат исто поле и двајцата тврдат дека се негов source of truth, архитектурата е нејасна.

На пример:

• Registration знае дека attendee има билет.
• Но Ticketing е source of truth за самиот билет.

Registration не треба да одржува паралелна „копија на вистината“ што може да стане различна од Ticketing.

11. Сопственост на податоците

Една од најважните системски одлуки во Evento е секој критичен податок да има јасен owner.

Data ownership одговара на прашањето:

На пример:

Надворешниот provider не е автоматски внатрешен Source of Truth

Payment provider потврдува external payment event.

Но Evento мора да има сопствен normalized payment state.

Provider dashboard е важен надворешен доказ.

Но production системот не треба за секој business decision во реално време да зависи од тоа некој човек рачно да отвори provider dashboard.

Derived Data не е Source of Truth

Dashboard може да покажува:

8.250 продадени билети.

Но dashboard projection не е source of truth.

Тоа е изведена состојба.

Ако projection се расипе, мора да може повторно да се изгради од authoritative domain data.

Денормализација е дозволена, двојна сопственост не е

Во практичен систем понекогаш е оправдано дел од податоците да се копираат за performance.

На пример:

• event title во analytics projection;
• organization name во read model;
• ticket summary во check-in projection.

Но мора да се знае дека тие се копии.

Authoritative owner останува еден.

12. Multi-Tenant Security Blueprint

Multi-tenancy е една од најважните архитектонски карактеристики на Evento.

Една физичка платформа опслужува повеќе независни организации.

Тоа значи дека секое барање мора да се разгледува не само во контекст на:

„Кој е корисникот?“

туку и:

„Во име на која организација дејствува и што му е дозволено да направи во таа организација?“

Tenant Context

Tenant context мора да биде server-resolved.

Backend не треба слепо да верува на:

само затоа што frontend го испратил.

Backend мора да потврди:

• кој е user;
• дали има membership;
• дали membership е активна;
• дали organization е активна;
• дали resource припаѓа на organization;
• дали user ја има потребната permission.

Defense in Depth

Tenant isolation не се потпира на една единствена проверка.

Evento користи повеќе слоеви:

Причината е едноставна:

контрола што постои само на едно место може да биде заборавена при нов endpoint или нов feature.

Tenant Key на Owned Data

Tenant-owned entities треба каде што е соодветно експлицитно да носат organization identifier.

На пример:

Ова овозможува појасен scope и подобра defense-in-depth контрола.

Negative Tests

Еден од најважните test suites во Evento не проверува:

„Дали корисникот може да го отвори својот event?“

туку:

„Дали корисникот навистина не може да го отвори туѓиот event?“

Cross-tenant negative tests треба да покриваат:

• read;
• update;
• delete;
• export;
• file access;
• API access;
• search;
• analytics;
• AI retrieval;
• support impersonation.

Tenant Isolation како Security Invariant

За некои reliability проблеми може да постои error budget.

За cross-tenant exposure не постои прифатлив budget.

13. Безбедносни правила без компромис

Од целиот security blueprint на Evento може да се извлече група правила што не треба да бидат предмет на ad-hoc компромис.

• MFA за privileged accounts.
• Deny by default.
• Без unscoped tenant queries.
• API secrets се чуваат hashed каде што моделот го дозволува тоа.
• Sessions мора да бидат безбедни и контролирани.
• Step-up authentication за чувствителни операции.
• Impersonation е контролирана и audit-ирана.
• Критичните операции создаваат audit trail.
• Production secrets никогаш не се чуваат во source code.
• Production PII не се копира во test environments.
• Webhooks се криптографски верификувани.
• Rate limiting постои на ризичните entry points.
• Permissions се експлицитни.
• Cross-tenant security suite е задолжителен release gate.

Deny by Default

Ако не постои експлицитна permission, операцијата се одбива.

Ова е побезбедно од моделот:

„Дозволи сè освен она што експлицитно сме го забраниле.“

Privileged Accounts

Platform admins, finance admins, security operators и други high-impact улоги мора да имаат повисоко ниво на заштита.

Тоа вклучува:

• MFA;
• step-up verification;
• stronger session controls;
• audit;
• поограничена impersonation;
• break-glass политика.

Support не е Super Admin

Еден support agent не треба по default да може:

• да гледа сите PII;
• да менува balances;
• да отвора туѓи organization records без причина;
• да export-ира customer data;
• да менува permissions.

Support tooling треба да биде дизајниран за решавање проблеми, не за заобиколување на security model.

14. Финансиски Blueprint

Evento содржи два различни финансиски домени што мора јасно да се разделат.

SaaS Billing

Во овој домен организацијата му плаќа на Evento за користење на платформата.

Тој опфаќа:

• plans;
• subscriptions;
• billing periods;
• trial;
• invoices;
• renewals;
• upgrades;
• downgrades;
• entitlements;
• payment collection.

Event Commerce

Во овој домен посетителот плаќа за билет, регистрација или друга event-related услуга.

Тој опфаќа:

• orders;
• payments;
• refunds;
• chargebacks;
• fees;
• ledger;
• reconciliation;
• organizer balances;
• payouts ако business model-от ги поддржува.

Овие два домена користат слични зборови, но не се ист business context.

Money во Minor Units

Финансиските суми се чуваат како цели броеви во најмалата валутна единица.

На овој начин се избегнуваат floating-point грешки.

Финансиски Lifecycle

Ledger

Финансиската историја не треба да се сведува на едно mutable поле:

Финансиски значајните настани треба да останат историски видливи.

На пример:

Историјата не се препишува.

Се додава нова корективна финансиска операција.

15. Клучна финансиска лекција

Најопасните financial bugs често не изгледаат драматично во code review.

Тие се појавуваат кога системот прави претпоставка што не е вистина.

Frontend Success Page не е Payment Confirmation

Корисникот може да стигне на:

а payment-от сè уште да не е финално потврден.

Затоа authoritative confirmation доаѓа од verified provider event и internal processing.

Еден Webhook Delivery не е доволен

Provider може:

• да го испрати webhook-от двапати;
• да го испрати доцна;
• да го испрати по timeout;
• да повтори delivery.

Системот мора да биде idempotent.

Mutable Status не е Financial History

Ако payment прво е:

paid

а потоа:

refunded

не треба да се изгуби информацијата дека некогаш навистина бил платен.

Provider Dashboard не е единствениот Record

Evento мора да може сам да објасни:

• што примил од provider;
• што обработил;
• кој business effect го создал;
• дали state се совпаѓа со provider.

Финансиските ефекти мора да бидат

• идемпотентни;
• проверливи;
• audit-ready;
• reconciliable;
• concurrency-safe;
• traceable.

16. Blueprint за комуникација

Комуникацијата во Evento не е спореден механизам што само „испраќа email“.

Таа е посебен домен што ги поврзува деловните настани со корисниците преку контролирани, верзионирани и мерливи пораки.

Основниот принцип е:

На пример, кога ќе се потврди регистрација, Registrations модулот не треба директно да повика конкретен email provider.

Тој треба да објави деловен настан:

Communication модулот потоа одлучува:

• дали треба да се испрати порака;
• кому треба да се испрати;
• преку кој канал;
• со кој template;
• со кој приоритет;
• како ќе се следи испораката.

Трансакциска, безбедносна и маркетинг комуникација

Овие три категории мора да бидат јасно разделени.

Трансакциска комуникација

Се испраќа како директна последица на корисничка или деловна операција.

Примери:

• потврда за регистрација;
• потврда за плаќање;
• издаден билет;
• издадена фактура;
• промена на регистрациски статус;
• потврда за refund.

Безбедносна комуникација

Се користи за критични security настани.

Примери:

• промена на лозинка;
• нов login од ризичен уред;
• MFA промена;
• промена на privileged permission;
• security alert.

Маркетинг комуникација

Се користи за промотивни пораки, campaigns и engagement.

Таа мора да ги почитува:

• consent;
• preferences;
• suppression;
• frequency rules;
• unsubscribe.

Priority Queues

Сите пораки не се подеднакво важни.

Ако email provider има проблем или queue се преоптовари, маркетинг пораките треба први да се паузираат.

Security и transactional communication мора да останат заштитени.

Versioned Templates

Email template не треба да биде само HTML текст што некој го менува директно во production.

Template-ите треба да бидат верзионирани.

Ова овозможува:

• audit;
• rollback;
• A/B тестирање каде што е соодветно;
• точно да се знае која порака ја добил корисникот.

Suppression Registry

Evento треба да има сопствен suppression регистар.

Причината е што delivery provider не треба да биде единственото место што знае дали некој recipient:

• се одјавил;
• има hard bounce;
• пријавил spam;
• е блокиран;
• не смее да прима маркетинг пораки.

Provider Abstraction

Communication domain не треба да зависи директно од еден конкретен email provider.

На тој начин промена на provider не бара промена во business logic.

17. AI Blueprint

AI во Evento не е една магична функција што се повикува од различни места со произволни prompts.

Тој е посебен платформски слој со сопствен governance модел.

Главната цел на AI Gateway е да спречи секој модул во системот самостојно да:

• избира provider;
• пишува prompt;
• испраќа чувствителни податоци;
• одлучува колку може да троши;
• прифаќа невалиден output;
• прави fallback без контрола.

Feature-Specific AI Contract

Секоја AI capability треба да има јасно дефиниран contract.

На пример:

Ова е многу подобро од:

Prompt Registry

Prompt-ите се product assets.

Тие треба да имаат:

• име;
• верзија;
• owner;
• purpose;
• input schema;
• output schema;
• model compatibility;
• evaluation history;
• active status.

Model Router

Не секоја AI задача бара ист модел.

Model Router може да избира според:

• квалитет;
• цена;
• latency;
• tenant plan;
• residency policy;
• feature criticality;
• provider availability.

AI е асистент, не авторитет

Во Evento AI може да биде:

• асистент;
• draft generator;
• analyzer;
• classification engine;
• productivity accelerator.

AI не е:

• source of truth;
• финансиски авторитет;
• security авторитет;
• неограничен operator;
• автономен publisher;
• замена за authorization.

Human Approval

За content што може да има деловно, правно или репутациско влијание, AI output мора да помине низ човечка одлука.

Permission-Aware Grounding

AI не смее да има пристап до повеќе податоци отколку корисникот што ја активирал функцијата.

Ако user нема permission да види financial report, AI не смее да го прочита тој report и да му го резимира.

AI Cost Governance

Секоја AI capability треба да има буџет.

Може да се дефинира:

• cost per request;
• daily feature budget;
• tenant budget;
• monthly package limit;
• batch budget;
• emergency kill threshold.

AI Fallback

Fallback не мора секогаш да значи друг AI provider.

Може да биде:

• друг модел;
• друг provider;
• cached output;
• rules-based fallback;
• човечки workflow;
• привремено исклучување на AI функцијата.

Core workflow мора да продолжи без AI.

18. AI правила без компромис

Од AI архитектурата произлегуваат неколку правила што Evento не треба лесно да ги прекршува.

• Provider independence.
• Versioned prompts.
• Structured output.
• Фактите што можат да се проверат се проверуваат.
• Human approval за чувствителни outputs.
• Tenant-aware retrieval.
• Permission-aware grounding.
• Feature-level cost budgets.
• Kill switch.
• Golden dataset.
• Evaluation pipeline.
• Fallback strategy.
• Incident response.
• Core workflow без AI.

Structured Output не значи Correct Output

Ако AI врати совршено валиден JSON, тоа докажува само дека структурата е валидна.

Не докажува дека содржината е фактички точна.

Golden Dataset

Секоја важна AI capability треба да има стабилен set од тест-примери врз кои се споредуваат:

• нов prompt;
• нов model;
• нов provider;
• нова output schema.

Без ова, AI квалитетот се оценува само субјективно.

AI Incident Response

AI може да има production incident дури и ако инфраструктурата е целосно online.

Примери:

• неквалитетен output;
• опасна hallucination;
• неочекувано голем cost spike;
• provider regression;
• tenant data leakage;
• prompt injection vulnerability.

Затоа AI има сопствени:

• alerts;
• dashboards;
• kill switch;
• rollback на prompt version;
• provider fallback;
• incident runbook.

19. Blueprint за квалитет

Квалитетот во Evento не започнува кога developer ќе заврши со кодирање и ќе му ја предаде функцијата на QA.

Тој започнува уште при дефинирањето на барањето.

Risk-Based Quality

Не секоја функција треба да добие ист test investment.

Ризикот се проценува според:

• customer impact;
• financial impact;
• security impact;
• data integrity;
• frequency of use;
• difficulty of recovery;
• blast radius.

Test Pyramid не е доволна сама по себе

Количината на unit tests не гарантира дека системот е безбеден.

На пример, payment webhook може да има 100% unit coverage и сепак да создаде duplicate charge ако никогаш не е тестиран со реална concurrency и duplicate delivery.

Production-Like Integration Tests

Critical flows треба да се тестираат во environment што е доволно сличен на production.

Тоа особено важи за:

• database transactions;
• queues;
• Redis;
• provider integrations;
• webhooks;
• migrations;
• concurrency.

Contract Tests

Секој critical API или provider adapter треба да има договор што автоматски се проверува.

Ако frontend очекува:

backend промена не смее тивко да воведе:

без contract change и versioning.

Production Validation

Release не е успешен само затоа што deployment pipeline завршил.

По production deployment се валидираат:

• technical health;
• critical journeys;
• SLO;
• error rate;
• business metrics;
• security signals.

20. Критични тест-пакети

Evento ги класифицира тестовите според ризикот што го покриваат.

P0 — Критични за системот

Овие тестови не смеат да паднат во production release.

• tenant isolation;
• privileged authorization;
• payment correctness;
• duplicate payment webhook;
• payment idempotency;
• ledger invariants;
• refund correctness;
• chargeback correctness;
• ticket overselling concurrency;
• ticket duplicate issuance;
• financial reconciliation;
• production database migrations.

P1 — Критични деловни текови

• registration;
• capacity management;
• waiting list;
• authentication;
• MFA;
• ticket validation;
• check-in;
• transactional notifications;
• SaaS subscriptions;
• backup restore.

P2 — Важни, но деградирачки функции

• analytics;
• reports;
• exports;
• AI content generation;
• AI summarization;
• marketing campaigns;
• recommendation features.

Release Gate

P2 функција може понекогаш да биде исклучена преку feature flag.

P0 failure не треба да се „прифати“ само затоа што release date е блиску.

21. DevOps Blueprint

DevOps во Evento не се сведува на една CI/CD pipeline конфигурација.

Тоа е целосен модел за контролирано движење на промена од development до production.

Pull Request како контролна точка

Секоја значајна промена треба да влезе преку Pull Request.

Таму се проверуваат:

• кодот;
• архитектонските граници;
• security impact;
• database changes;
• API contracts;
• test coverage;
• migration risk;
• operational impact.

Quality Gates

Pipeline-от не треба да продолжи само затоа што кодот успешно се компајлира.

Минималните gates може да вклучуваат:

• linting;
• static analysis;
• unit tests;
• integration tests;
• contract tests;
• tenant isolation tests;
• security scan;
• dependency vulnerability scan;
• architecture tests;
• migration validation.

Immutable Artifact

Production не треба да го гради application artifact-от повторно од source code.

Артефактот што е тестиран е истиот што се пушта во production.

Staging

Staging треба што е можно повеќе да личи на production.

Тоа не значи иста големина на инфраструктура, туку ист тип на runtime, конфигурација и зависности каде што е практично.

На staging се проверуваат:

• deployment;
• migrations;
• provider integrations;
• critical flows;
• feature flags;
• observability.

Canary Release

Наместо новата верзија веднаш да добие 100% од production traffic, Evento може прво да ја изложи на мал дел од сообраќајот.

Во секој чекор се следат:

• error rate;
• latency;
• SLO burn rate;
• database pressure;
• queue health;
• business metrics.

Rollback

Rollback мора да биде однапред дефиниран, не измислен за време на incident.

Треба да се знае:

• која верзија е последно стабилна;
• дали database migration е backward compatible;
• дали feature flag може да го исклучи ризичниот feature;
• дали worker-и од старата и новата верзија може кратко да коегзистираат;
• како се валидира recovery.

Expand–Contract Migrations

Database changes што можат да влијаат на zero-downtime deployment треба да следат expand–contract модел.

Ова е побезбедно од директно бришење на поле што старата верзија сè уште го користи.

22. Production Blueprint

Production моделот на Evento започнува со една едноставна претпоставка:

Секој критичен сервис мора да има јасен owner, мерлива reliability цел и однапред дефиниран начин на реакција кога ќе се појави проблем.

Production моделот ги вклучува:

• service catalog;
• explicit ownership;
• SLI;
• SLO;
• SLA каде што постои;
• error budgets;
• dashboards;
• alerts;
• on-call;
• runbooks;
• capacity planning;
• autoscaling;
• graceful degradation;
• disaster recovery;
• game days;
• post-incident reviews;
• FinOps.

Service Catalog

За секој критичен сервис треба да постои централен запис со:

• име;
• business purpose;
• owner;
• criticality;
• dependencies;
• SLI/SLO;
• RTO/RPO;
• dashboard;
• alerts;
• runbook;
• deployment pipeline;
• cost center.

Business SLI

Production health не се мери само со:

„Server is up.“

Се мери со тоа дали критичниот business flow функционира.

На пример:

• registration success rate;
• payment confirmation correctness;
• ticket issuance latency;
• check-in latency;
• transactional delivery latency.

Error Budgets

Error budget ја претвора reliability во управувачка одлука.

Ако budget се троши пребрзо, release velocity се намалува и приоритет се дава на стабилизација.

On-Call

Tier 0 и Tier 1 services мора да имаат јасна on-call одговорност.

On-call инженерот мора да има:

• dashboard;
• alert context;
• runbook;
• scoped access;
• escalation path;
• safe remediation tools.

Runbooks

Runbook-от треба да објасни што да се направи кога конкретен failure mode ќе се случи.

Не треба да биде општа документација.

Тој треба да содржи:

• симптоми;
• severity guidance;
• immediate actions;
• diagnostics;
• stabilization;
• fallback;
• recovery;
• validation;
• escalation;
• communication.

Capacity Planning

Capacity planning не започнува кога CPU ќе достигне 95%.

Треба однапред да се знае:

• очекуван peak;
• current headroom;
• database capacity;
• queue throughput;
• provider limits;
• autoscaling limits;
• cost impact.

Disaster Recovery

Backup е само еден дел од recovery моделот.

DR мора да покрива:

• database restore;
• object storage restore;
• region failure;
• DNS;
• secrets;
• certificates;
• infrastructure recreation;
• business-state validation.

FinOps

Production scaling мора да има финансиска видливост.

Evento треба да знае:

• cost per service;
• cost per tenant;
• cost per feature;
• AI cost;
• provider cost;
• storage cost;
• cost-to-serve;
• contribution margin.

23. Редослед за Graceful Degradation

Кога системот е под силен притисок, сите функции не треба да имаат еднаков приоритет.

Evento однапред дефинира кои capabilities може први да се ограничат и кои мора да останат заштитени што е можно подолго.

Прво се ограничуваат

Овие функции имаат деловна вредност, но нивното привремено ограничување е помалку штетно од прекин на core flow.

Core capabilities што се заштитуваат

• authentication;
• tenant isolation;
• registration;
• payments;
• ticket issuance;
• ticket validation;
• check-in;
• security notifications.

Operational Priority Model

Овој модел треба да биде имплементиран во:

• queue priorities;
• worker pools;
• rate limits;
• autoscaling;
• feature flags;
• load shedding;
• incident runbooks.

Graceful Degradation не е Failure

Ако AI summary е привремено недостапен, но регистрациите и плаќањата продолжуваат, системот не е целосно паднат.

Тој работи во деградиран режим.

Ова е многу подобро од архитектура во која еден некритичен dependency го повлекува целиот систем.

24. Главни архитектонски ризици

Финалниот blueprint мора експлицитно да ги покаже најголемите ризици на системот.

Архитектура што зборува само за components, а не и за failure modes, е некомплетна.

Risk Register е жив документ

Ризиците не се дефинираат еднаш и потоа се забораваат.

Risk Register треба периодично да се ажурира според:

• production incidents;
• нови features;
• нови providers;
• архитектонски промени;
• нови enterprise барања;
• security findings;
• cost trends;
• регулаторни барања.

Risk Ownership

Секој значаен ризик треба да има owner.

25. Консолидиран ADR регистар

Architecture Decision Records се инженерската меморија на Evento.

Тие не кажуваат само што е избрано.

Тие треба да објаснат и:

• кој проблем се решавал;
• кои опции биле разгледани;
• зошто е донесена одлуката;
• кои последици ги носи;
• кога одлуката треба повторно да се разгледа.

Product и Architecture

• ADR-001 — Modular Monolith.
• ADR-002 — PostgreSQL како примарна трансакциска база.
• ADR-003 — Централен AI Gateway.
• ADR-004 — Shared Database Multi-Tenant модел.
• ADR-005 — Hybrid Identifiers.
• ADR-006 — Domain Events со Transactional Outbox.
• ADR-007 — Tenant Key на tenant-owned data.

API и Backend

• ADR-008 — REST API за MVP.
• ADR-009 — URL-based API Versioning.
• ADR-010 — Standard Error Envelope.
• ADR-011 — Idempotency за критични commands.
• ADR-012 — Provider Adapters.
• ADR-013 — Layered Modules.
• ADR-014 — Practical CQRS.
• ADR-015 — Domain Model независен од Eloquent.
• ADR-016 — Module Communication преку Contracts и Events.
• ADR-017 — Transactional Outbox.

Frontend и Security

• ADR-018 — Feature-First Vue Architecture.
• ADR-019 — Controlled State Management.
• ADR-020 — Central API Client.
• ADR-021 — Governed Design System.
• ADR-022 — Hybrid Rendering.
• ADR-023 — Membership-Based Roles.
• ADR-024 — Server-Resolved Tenant Context.
• ADR-025 — Deny by Default.
• ADR-026 — MFA за privileged accounts.
• ADR-027 — Hashed API Secrets.
• ADR-028 — Controlled Impersonation.

Финансии, комуникација и AI

• ADR-029 — Separate Billing Domains.
• ADR-030 — Money in Minor Units.
• ADR-031 — Webhook-Confirmed Payments.
• ADR-032 — Append-Only Ledger.
• ADR-033 — Entitlements.
• ADR-034 — Payment Provider Abstraction.
• ADR-035 — Communication Bounded Context.
• ADR-036 — Event-Driven Notifications.
• ADR-037 — Versioned Templates.
• ADR-038 — Independent Suppression Registry.
• ADR-039 — Priority Queues.
• ADR-040 — Human Approval for AI Campaigns.
• ADR-041 — Central AI Gateway.
• ADR-042 — Provider-Independent AI Contracts.
• ADR-043 — Prompt Registry.
• ADR-044 — Structured AI Output.
• ADR-045 — Human Approval.
• ADR-046 — AI не е Core Dependency.
• ADR-047 — Feature-Level AI Budgets.
• ADR-048 — Permission-Aware Grounding.

Квалитет, испорака и операции

• ADR-049 — Risk-Based Quality.
• ADR-050 — Production-Like Integration Testing.
• ADR-051 — Contract Testing Gate.
• ADR-052 — Mandatory Tenant Isolation Suite.
• ADR-053 — AI Evaluation Pipeline.
• ADR-054 — Controlled Test Data.
• ADR-055 — Immutable Deployment Artifacts.
• ADR-056 — Expand–Contract Database Migrations.
• ADR-057 — Feature Flags.
• ADR-058 — Logs, Metrics и Distributed Traces.
• ADR-059 — Canary Releases.
• ADR-060 — SLO-Driven Operations.
• ADR-061 — Horizontal Scaling by Default.
• ADR-062 — Graceful Degradation.
• ADR-063 — Single Region First, Multi-Region by Evidence.
• ADR-064 — Service Catalog и Explicit Ownership.
• ADR-065 — FinOps како Engineering Input.
• ADR-066 — Microservices само по експлицитни Extraction Criteria.

ADR Traceability

ADR не треба да живее изолирано од implementation.

Таму каде што е практично, треба да постои врска меѓу:

На пример:

Во тој момент ADR престанува да биде само документација.

Станува активен дел од engineering governance.

26. Клучна лекција од ADR регистарот

Архитектурата не е еден голем дијаграм.

Таа е збир од одлуки што заедно создаваат систем.

Секоја од тие одлуки има:

• контекст;
• проблем што се решава;
• разгледани опции;
• избрана насока;
• компромиси;
• последици;
• услови под кои одлуката треба повторно да се разгледа.

ADR регистарот ја зачувува инженерската меморија на проектот.

Без него, по неколку месеци тимот лесно заборава:

• зошто е избран Modular Monolith;
• зошто tenant context се решава на server side;
• зошто плаќањата се потврдуваат преку webhook;
• зошто AI не е core dependency;
• зошто migrations се прават со expand–contract модел;
• зошто microservices не се воведени од првиот ден.

Кога причината ќе се заборави, одлуката почнува да изгледа произволна.

Тогаш некој може да предложи промена што технички изгледа логична, но всушност го поништува проблемот што првичната одлука го решавала.

ADR не е догма

Architecture Decision Record не значи дека одлуката никогаш повеќе не смее да се промени.

Напротив.

Добар ADR треба да овозможи нов тим подоцна да каже:

Така архитектурата еволуира контролирано.

Одлуките треба да се поврзуваат

Вистинската вредност на ADR регистарот се гледа кога одлуките се поврзуваат меѓусебно.

На пример:

Ова не се пет независни одлуки.

Тие заедно формираат еден multi-tenant security model.

Исто важи и за payment architecture:

Архитектурата станува силна кога правилата се надополнуваат, а не кога постојат како изолирани препораки.

27. План за имплементација

Финалниот blueprint нема вредност ако не може да се претвори во реален план за испорака.

Implementation Roadmap на Evento затоа е организиран по dependency order, а не само по тоа кои функции се најинтересни за demo.

Основната логика е:

Фаза 0 — Foundation

Пред да се изградат видливите product features, се поставува инженерската основа.

• repository структура;
• coding standards;
• branch и pull-request правила;
• Docker development environment;
• CI pipeline;
• environment strategy;
• configuration management;
• secrets management;
• base logging;
• metrics;
• error tracking;
• authentication skeleton;
• tenant context;
• database conventions;
• migration strategy;
• module boundaries.

Оваа фаза не создава многу впечатливи screenshots.

Но го одредува квалитетот на секоја фаза што следува.

Фаза 1 — Core SaaS

Прво се создава основната SaaS структура.

• organizations;
• organization lifecycle;
• memberships;
• invitations;
• roles;
• permissions;
• tenant switching;
• event management;
• public event pages;
• basic audit trail.

На крајот на оваа фаза organizer треба безбедно да може:

Фаза 2 — Registration and Ticketing

Следно се имплементира главниот attendee journey.

• registration forms;
• custom registration fields;
• capacity rules;
• ticket types;
• waiting list;
• registration status lifecycle;
• ticket issuance;
• QR generation;
• ticket validation;
• online check-in;
• concurrency protection.

Фаза 3 — Payments

Плаќањата се воведуваат откако registration domain веќе има стабилен lifecycle.

• orders;
• money model;
• payment intent;
• payment provider adapter;
• signed webhooks;
• idempotency;
• payment state normalization;
• ledger;
• refunds;
• chargebacks;
• reconciliation;
• financial audit.

Клучниот integrated flow станува:

Фаза 4 — Communication

• transactional email;
• security notifications;
• template registry;
• template versioning;
• priority queues;
• provider adapters;
• delivery events;
• retry;
• suppression registry;
• communication analytics.

Фаза 5 — Analytics and AI

Analytics и AI се додаваат врз веќе стабилни domain events и податоци.

• organizer dashboard;
• business KPIs;
• analytics projections;
• reporting;
• AI Gateway;
• Prompt Registry;
• event-description generator;
• feedback summarization;
• AI budgets;
• AI evaluation;
• kill switch.

Фаза 6 — Production Hardening

Последната фаза пред сериозен launch не е „уште features“.

Таа е системско зајакнување.

• performance testing;
• load testing;
• security review;
• penetration testing каде што е оправдано;
• accessibility;
• production observability;
• SLO;
• alerts;
• runbooks;
• backup restore validation;
• Disaster Recovery;
• Game Day;
• launch readiness review.

Roadmap не е календар

Овие фази не значат дека секоја мора да трае ист број недели.

Roadmap ја дефинира dependency логиката.

Реалниот timeline се адаптира според:

• тим;
• budget;
• market deadline;
• ризик;
• feedback;
• технички откритија.

28. Модел на тим

Архитектурата не функционира независно од луѓето што ја градат.

Добар технички модел со нејасна ownership структура брзо создава bottlenecks и operational gaps.

Примерен MVP тим за Evento може да изгледа вака:

Мал тим не значи дека одговорностите исчезнуваат

Во реална startup средина е можно една личност да носи повеќе улоги.

На пример:

• Tech Lead може да биде и senior backend engineer;
• DevOps може делумно да го покрива backend тимот;
• Product Manager може да ги преземе дел од BA обврските;
• дизајнер може да биде external или part-time.

Но улогите и одговорностите сепак мора да бидат видливи.

Ако нема dedicated Security Engineer, тоа не значи:

„Security никој не ја поседува.“

Значи дека Tech Lead или друг конкретен owner ја носи таа одговорност со периодична надворешна експертиза.

Ownership Matrix

За критичните домени може да постои едноставна матрица:

29. Оперативен ритам

Добрата архитектура и добриот roadmap не се доволни ако тимот нема ритам во кој редовно ги проверува квалитетот, ризикот и деловните резултати.

Evento користи различен cadence за различни типови одлуки.

Дневно

• краток team sync;
• активни blockers;
• critical alerts;
• production incidents;
• critical business metrics;
• release status.

Дневниот ритам не треба да стане долг status meeting.

Целта е брзо да се идентификува што може да го блокира delivery или production.

Неделно

• sprint review;
• product progress;
• architecture review;
• quality review;
• нови risks;
• incident corrective actions;
• customer feedback;
• business KPI.

Месечно

• SLO review;
• error budget review;
• cost review;
• FinOps review;
• security review;
• access review за критични роли;
• AI quality review;
• AI cost review;
• support trends;
• roadmap adjustment.

Квартално

• capacity review;
• Disaster Recovery test;
• architecture evolution review;
• provider strategy;
• major dependency review;
• security posture review;
• business outcome review;
• product strategy adjustment.

Не секоја тема бара meeting

Operating cadence не значи calendar да се наполни со состаноци.

Дел од review-ите може да бидат автоматизирани dashboards, written reports или asynchronous reviews.

Важно е одлуката да има ритам, не нужно состанок.

30. Definition of Ready

Development не треба да започне само затоа што во backlog постои задача со наслов.

Задачата е подготвена за развој кога тимот има доволно јасна слика што треба да се изгради и кои ризици треба да се контролираат.

Минимални критериуми

• проблемот е јасно дефиниран;
• business value е објаснета;
• scope е дефиниран;
• out-of-scope е познат каде што е важно;
• acceptance criteria постојат;
• UX е доволно подготвен;
• dependencies се познати;
• domain owner е познат;
• data classification е направена;
• security impact е разгледан;
• tenant impact е разгледан;
• financial impact е разгледан ако постои;
• analytics requirements се дефинирани;
• observability expectations се познати;
• rollout strategy е позната;
• главните test scenarios се идентификувани.

Пример — недоволно подготвена задача

Ова остава премногу неодговорени прашања:

• целосен или делумен refund?
• кој има permission?
• дали ticket станува invalid?
• како се менува registration?
• како се менува ledger?
• што ако provider timeout-ира?
• што ако webhook дојде двапати?
• како корисникот се известува?
• како се прави reconciliation?

Подготвена задача

Definition of Ready го намалува rework-от и ја спречува архитектурата да се измислува додека developer веќе пишува production code.

31. Definition of Done

Задача не е завршена само затоа што кодот работи на developer laptop.

Во Evento, „готово“ значи дека capability е подготвена за безбедно production користење во обемот што е договорен.

Минимален Definition of Done

• кодот е имплементиран;
• code review е завршен;
• domain rules се тестирани;
• authorization е тестирана;
• tenant isolation е потврдена;
• API contract е ажуриран;
• database migrations се безбедни;
• frontend loading state е завршен;
• empty state е завршен;
• error state е завршен;
• responsive behavior е проверен;
• accessibility е проверена;
• observability е додадена;
• важните metrics постојат;
• security review е завршен според ризикот;
• documentation е ажурирана;
• runbook е ажуриран ако е потребно;
• rollout strategy е подготвена;
• rollback или fallback е дефиниран;
• Product Owner ја прифатил функционалноста.

Definition of Done зависи од ризикот

Мал текстуален UI fix нема ист production burden како нов payment flow.

Затоа DoD може да има основен слој и дополнителни risk-based проверки.

За payment feature може дополнително да се бара:

• idempotency test;
• duplicate webhook test;
• reconciliation test;
• concurrency test;
• ledger validation;
• provider failure test.

За AI feature:

• golden dataset evaluation;
• prompt versioning;
• cost estimate;
• output validation;
• human-approval flow;
• kill-switch verification.

За tenant-sensitive feature:

• cross-tenant negative tests;
• permission matrix test;
• audit verification.

Production Done

За големи capabilities може да постои уште едно ниво:

production validated.

32. Што намерно не направивме

Еден од најважните знаци на зрелост во SaaS архитектурата е способноста свесно да се каже:

„Ова сега нема да го градиме.“

Evento намерно не воведе одредени технологии, архитектонски модели и продуктни области во почетната верзија.

Не затоа што тие се лоши.

Туку затоа што во конкретниот контекст не создаваат доволно вредност за сложеноста што ја носат.

Не воведовме Microservices од првиот ден

Причината е што Modular Monolith подобро одговара на:

• големината на тимот;
• фазата на производот;
• брзината на развој;
• ниското оперативно оптоварување;
• потребата доменските граници прво да се докажат.

Microservices остануваат можна иднина, но само кога production evidence ќе покаже реална потреба.

Не воведовме Kafka без јасна потреба

Event-driven архитектура не значи автоматски дека е потребен голем distributed streaming platform.

За почетниот обем, transactional outbox, queue инфраструктура и јасно дефинирани domain events се доволни.

Kafka или сличен систем има смисла кога постои реална потреба за:

• многу висок event throughput;
• голем број независни consumers;
• долготрајно чување и replay на event streams;
• stream processing;
• меѓусервисна integration backbone архитектура.

Kubernetes не е автоматска цел

Container orchestration е алатка, не знак дека системот е „enterprise“.

Ако поедноставна managed infrastructure може сигурно да ги исполни:

• availability;
• autoscaling;
• deployment;
• observability;
• recovery;
• cost requirements;

тогаш дополнителниот Kubernetes overhead нема автоматски деловна вредност.

Не користиме сложен Event Sourcing за секој модул

Append-only financial ledger е оправдан бидејќи финансиската историја мора да биде проверлива.

Но тоа не значи дека секој domain entity мора да биде реконструиран од event stream.

Сложеноста мора да биде оправдана од реален domain requirement.

Не воведовме Active-Active Multi-Region

Active-active архитектурата може да обезбеди висока достапност и ниска регионална латентност, но носи значителна сложеност:

• distributed writes;
• conflict resolution;
• cross-region consistency;
• financial coordination;
• повисоки инфраструктурни трошоци;
• посложено debugging.

Evento прво користи силен single-region модел со disaster recovery и подоцна ја преиспитува одлуката ако enterprise SLA, residency или реалниот traffic го оправдаат тоа.

Не воведовме неограничени AI агенти

AI нема автономен пристап до критични системски операции.

Не дозволуваме AI самостојно да:

• менува финансиски податоци;
• менува permissions;
• прави production configuration changes;
• испраќа масовни campaigns без approval;
• брише критични records;
• донесува security decisions.

Не градиме сопствен Payment Processor

Evento не треба да стане payment infrastructure company ако тоа не е основната деловна стратегија.

Се користат специјализирани payment providers преку јасен abstraction layer.

Не градиме сопствен Email Delivery Engine

Communication domain е наш.

Delivery infrastructure не мора да биде.

Evento управува со:

• templates;
• priorities;
• preferences;
• suppression;
• delivery state;
• analytics.

Но физичкото доставување го делегира на специјализиран provider.

Не градиме сопствен Identity Provider без потреба

Authentication и authorization се критични, но тоа не значи дека секоја криптографска и identity capability мора да биде развиена од нула.

Таму каде што постои зрел и безбеден стандард или provider, треба да се користи.

Не дозволивме бесконечен MVP Scope

Можеби најважната намерна одлука е што Evento не се обиде во првата верзија да биде:

• CRM;
• ERP;
• marketing suite;
• video platform;
• social network;
• marketplace;
• AI automation suite;
• financial management platform.

Секоја од овие области може да се разгледа подоцна.

Но само ако customer evidence го оправда проширувањето.

33. Најважни продуктни лекции

Лекција 1 — Проблемот е поважен од функцијата

Product discovery не започнува со:

„Кои features треба да ги имаме?“

Туку со:

„Кој проблем е доволно важен за клиентот да сака да го реши?“

Функцијата е само еден можен механизам за решавање на проблемот.

Лекција 2 — MVP мора да биде комплетен, не огромен

MVP не мора да има многу функции.

Но мора да може целосно да го реши основниот customer journey.

За Evento тоа значи:

Лекција 3 — Roadmap е стратегија, не список на желби

Добар roadmap покажува:

• што е најважно;
• што зависи од што;
• што е намерно одложено;
• која хипотеза се валидира;
• кој business outcome се очекува.

Roadmap што содржи сè што некогаш некој предложил не е roadmap.

Тоа е backlog без приоритет.

Лекција 4 — AI мора да создава мерлива деловна вредност

„Имаме AI“ не е продуктна стратегија.

Треба да може да се измери дали AI:

• заштедува време;
• зголемува conversion;
• го подобрува content quality;
• го намалува support workload;
• создава дополнителен приход.

Лекција 5 — Scope Control е форма на лидерство

Добриот Product Manager не додава само идеи.

Тој знае и кога да каже:

„Не сега.“

Заштитата на фокусот е една од најважните продуктни одговорности.

34. Најважни архитектонски лекции

Лекција 1 — Едноставната архитектура често е посилна архитектура

Архитектонската зрелост не се мери според бројот на технологии.

Се мери според тоа дали системот:

• е разбирлив;
• може да се тестира;
• може да се deploy-ира;
• може да се дебагира;
• може да се обнови;
• може да се промени.

Лекција 2 — Module Boundaries се поважни од Deployment Boundaries

Лошо дизајнирани microservices не создаваат добра архитектура.

Добро дизајнирани module boundaries во Modular Monolith создаваат многу подобра основа за идно издвојување.

Лекција 3 — Data Ownership мора да биде експлицитен

Ако два модула веруваат дека се owner на истиот business fact, со текот на времето ќе се појави конфликт.

Секој критичен податок треба да има еден authoritative owner.

Лекција 4 — Providers мора да бидат заменливи

Payment, email и AI providers се надворешни dependencies.

Тие не треба да ја диктираат внатрешната domain architecture.

Лекција 5 — Архитектонска одлука без Operational Model е некомплетна

Ако архитектурата кажува:

„Ќе користиме Redis.“

тоа не е доволно.

Треба да знаеме:

• за што;
• што ако падне;
• дали е source of truth;
• како се следи;
• како се обновува;
• колкав е impact-от.

35. Најважни безбедносни лекции

Лекција 1 — Tenant Isolation мора да биде системска

Multi-tenant security не смее да зависи од тоа developer-от секогаш да се сети рачно да додаде:

Isolation мора да се спроведува преку повеќе слоеви.

Лекција 2 — Authorization не е Frontend Concern

Скриено копче не значи забранета операција.

Backend мора секогаш да ја спроведе конечната authorization одлука.

Лекција 3 — Privilege мора да биде минимален и audit-иран

Колку е помоќна улогата, толку повеќе треба да има:

• ограничен scope;
• MFA;
• step-up authentication;
• audit trail;
• периодичен access review.

Лекција 4 — Support Access е Security Surface

Support tools често имаат пристап до најчувствителните делови од системот.

Затоа мора да бидат дизајнирани со исто внимание како admin panel-от.

Лекција 5 — Најопасна е контролата што лесно може да се заборави

Добриот security model ги претвора правилата во:

• middleware;
• policies;
• repository scopes;
• database constraints;
• automated tests;
• CI gates.

36. Најважни финансиски лекции

Лекција 1 — Payment Success Page не е Payment Confirmation

Browser redirect не е финансиски доказ.

Verified provider event и internal processing се authoritative flow.

Лекција 2 — Idempotency е задолжителна

Финансиски систем мора безбедно да обработи:

• duplicate request;
• duplicate webhook;
• retry;
• network timeout;
• replayed job.

без duplicate financial effect.

Лекција 3 — Status без Ledger не е доволен

Поле:

не објаснува:

• колку било платено;
• колку било refund-ирано;
• дали имало fee;
• дали имало chargeback;
• дали chargeback бил reversed.

Лекција 4 — Reconciliation е дел од архитектурата

Internal payment state периодично мора да се спореди со provider state.

Тоа не е само Finance процедура.

Тоа е системска reliability контрола.

Лекција 5 — Финансиска корекција не ја брише историјата

Ако операцијата треба да се коригира, се создава нова корективна ledger операција.

Старата не исчезнува.

37. Најважни AI лекции

Лекција 1 — AI Demo е лесно; AI Production е системска дисциплина

API call до модел може да се направи за неколку минути.

Production AI бара многу повеќе:

• contracts;
• validation;
• evaluation;
• security;
• cost control;
• fallback;
• observability;
• incident management.

Лекција 2 — Prompt-ите се верзионирани продуктни артефакти

Prompt што влијае на customer experience треба да има:

• верзија;
• owner;
• evaluation;
• rollback.

Лекција 3 — Structured Output не гарантира фактичка точност

Валиден JSON може да содржи целосно неточни факти.

Schema validation и fact validation се различни проблеми.

Лекција 4 — Human Approval мора реално да постои во Workflow

Не е доволно во policy документ да пишува:

„User should review AI output.“

Interface-от треба навистина да има:

• preview;
• approve;
• edit;
• reject.

Лекција 5 — Core Business Flow мора да работи без AI

Ако AI provider падне, Evento може да изгуби AI convenience.

Не смее да изгуби:

• registration;
• payments;
• ticketing;
• check-in.

38. Најважни оперативни лекции

Лекција 1 — Uptime не е доволен

Application може да биде online, а business flow да биде неупотреблив.

Затоа се мерат:

• registration success;
• payment correctness;
• ticket issuance;
• check-in latency;
• notification delivery.

Лекција 2 — Alerts мора да бидат actionable

Alert што никој не знае што да направи со него е шум.

Добар alert има:

• owner;
• severity;
• customer impact;
• context;
• runbook.

Лекција 3 — Backup без Restore Test е претпоставка

Успешно креиран backup не докажува дека системот може да се врати.

Restore мора реално да се тестира.

Лекција 4 — Scaling мора да биде и финансиски одржлив

Систем што успешно скалира од 1.000 на 100.000 корисници, но троши повеќе отколку што заработува, нема одржлив scaling model.

Лекција 5 — Incident Review треба да го подобри системот, а не да најде виновник

Добриот post-incident review создава:

• нова контрола;
• подобар alert;
• нов test;
• подобар runbook;
• архитектонска промена;
• јасна corrective action.

39. Повторно употреблив SaaS Blueprint

Evento е конкретна платформа за управување со настани, но процесот со кој е дизајниран може да се примени на многу други SaaS производи.

На пример:

• booking platform;
• learning management system;
• marketplace;
• membership platform;
• CRM;
• clinic management software;
• veterinary software;
• logistics platform;
• HR SaaS;
• property management platform;
• subscription content system;
• sports management platform.

Доменските ентитети ќе бидат различни.

Но процесот останува сличен:

Чекор 1 — Разбери го проблемот

Пред кодирање треба да се разберат:

• корисниците;
• pain points;
• деловниот процес;
• вредноста;
• ризиците.

Чекор 2 — Дефинирај го производот

Подготви:

• BRD;
• PRD;
• personas;
• journeys;
• MVP;
• roadmap.

Чекор 3 — Дефинирај го доменот

Идентификувај:

• bounded contexts;
• entities;
• value objects;
• aggregates;
• business invariants;
• data ownership.

Чекор 4 — Дизајнирај ја архитектурата

Одлучи:

• application style;
• API;
• database;
• integration model;
• queue architecture;
• provider abstractions;
• observability.

Чекор 5 — Дефинирај ги границите на ризикот

За секој SaaS треба да се разгледаат:

• authentication;
• authorization;
• tenant isolation ако е multi-tenant;
• PII;
• financial data;
• audit;
• support access;
• provider risk.

Чекор 6 — Вгради Quality Engineering

Ризичните flows треба да добијат најсилни tests.

Чекор 7 — Дизајнирај Production пред Production

Уште пред launch треба да се знаат:

• SLO;
• alerts;
• runbooks;
• backup;
• restore;
• rollback;
• capacity;
• cost model.

Чекор 8 — Подобрувај според Evidence

Архитектурата не треба да расте според мода.

Треба да расте според:

• production metrics;
• customer feedback;
• reliability data;
• cost data;
• business outcomes.

40. Финален регистар на проектни артефакти

На крајот од case study-то, Evento не постои само како source code.

Постојат повеќе групи артефакти што заедно ја опишуваат целата платформа.

Деловни артефакти

• Product Vision;
• Discovery Findings;
• Stakeholder Map;
• Business Process Maps;
• BRD;
• Business Rules;
• Risk Register;
• KPI Framework;
• Business Case.

Продуктни артефакти

• PRD;
• Personas;
• User Journeys;
• Epics;
• User Stories;
• Acceptance Criteria;
• MVP Scope;
• Roadmap;
• Release Plan;
• Feature Prioritization.

Архитектонски артефакти

• C4 diagrams;
• System Context;
• Container Architecture;
• Bounded Context Registry;
• Context Map;
• Domain Model;
• ER Model;
• Data Ownership Registry;
• API Contracts;
• Integration Contracts;
• ADR Register.

Инженерски артефакти

• Backend structure;
• Frontend structure;
• Module conventions;
• Design System rules;
• Security model;
• Tenant isolation model;
• Financial model;
• Ledger model;
• Communication architecture;
• AI Gateway architecture;
• Provider adapter contracts.

Артефакти за квалитет

• Test Strategy;
• Risk-Based Test Matrix;
• P0/P1/P2 Test Suites;
• Security Test Plan;
• Tenant Isolation Suite;
• Performance Test Plan;
• Load Test Scenarios;
• AI Evaluation Framework;
• Golden Dataset;
• UAT Plan;
• Release Gates.

Артефакти за испорака

• Git Workflow;
• CI Pipeline;
• CD Pipeline;
• Docker Strategy;
• Environment Strategy;
• Infrastructure as Code;
• Secrets Strategy;
• Migration Strategy;
• Rollback Plan;
• Release Checklist.

Оперативни артефакти

• Service Catalog;
• Ownership Registry;
• SLI Catalog;
• SLO Catalog;
• Error Budget Policy;
• Dashboards;
• Alert Catalog;
• Runbooks;
• On-Call Model;
• Capacity Model;
• Scaling Plan;
• Disaster Recovery Plan;
• RTO/RPO Registry;
• Backup Policy;
• Restore Validation;
• Game Day Scenarios;
• Incident Process;
• Post-Incident Review Template;
• FinOps Model.

Артефакти за управување

• Definition of Ready;
• Definition of Done;
• Production Readiness Checklist;
• Architecture Review Process;
• Security Review Process;
• Change Management Policy;
• Risk Review Cadence;
• ADR Governance.

Единствена слика на системот

Секој од овие артефакти опишува различен аспект на Evento.

Но тие не треба да си противречат.

Ако business requirement бара силна tenant isolation, тоа треба да се гледа во:

• PRD;
• architecture;
• database design;
• authorization;
• tests;
• monitoring;
• incident classification.

Ако едно правило постои само во еден документ, а не и во системот, traceability е прекината.

41. Финално извршно резиме

Evento е дизајниран како целосен SaaS систем во кој продуктот, архитектурата, безбедноста, финансиските текови, квалитетот и production операциите не се третираат како одделни светови.

Сите тие се дел од еден ист управувачки модел.

Финалната архитектонска и продуктна позиција на Evento може да се сумира вака:

Неговата најголема сила не е конкретниот framework, database engine или cloud provider.

Најголемата сила е што критичните одлуки имаат јасна причина, а секоја причина е поврзана со конкретен ризик, деловна потреба или operational requirement.

Product-Driven

Evento не започна со технологија.

Започна со деловен проблем.

Од таму се дефинираа:

• целните корисници;
• главните pain points;
• customer journeys;
• MVP;
• roadmap;
• мерливите business outcomes.

Modular

Системот започнува како Modular Monolith со експлицитни доменски граници.

Тоа овозможува:

• брзо delivery;
• пониска operational complexity;
• јасно ownership;
• подобро тестирање;
• идно издвојување на сервиси само кога постои доказ дека тоа е потребно.

Multi-Tenant

Multi-tenancy не е само database convention.

Таа е security и domain property на целиот систем.

Tenant isolation се спроведува преку:

• membership;
• server-resolved tenant context;
• permissions;
• resource ownership;
• repository scoping;
• negative security tests;
• audit.

Secure

Security не е финална ревизија пред launch.

Таа е вградена во:

• authentication;
• authorization;
• tenant boundaries;
• API design;
• support access;
• production access;
• secrets;
• webhooks;
• testing;
• operational monitoring.

Финансиски проверлив

Evento не ја третира финансиската состојба како mutable status field.

Финансиските операции се изградени врз:

• money in minor units;
• signed provider events;
• idempotency;
• append-only ledger;
• reconciliation;
• refunds;
• chargebacks;
• audit.

Независен од Provider

Payment, email и AI providers се заменливи инфраструктурни зависности.

Нивните модели не ја диктираат внатрешната архитектура на Evento.

AI-Enabled

AI е интегриран како контролиран платформски слој.

Тој има:

• AI Gateway;
• Prompt Registry;
• versioning;
• structured outputs;
• evaluation;
• budgets;
• guardrails;
• human approval;
• fallback;
• kill switch.

Но core business flow не зависи од AI.

Observable

Production health не се сведува на тоа дали серверот е online.

Се следат:

• logs;
• metrics;
• traces;
• SLI;
• SLO;
• error budgets;
• business journeys;
• cost metrics.

Scalable

Evento не се обидува однапред да ја реши секоја идна scaling потреба.

Наместо тоа користи staged scaling model:

Operationally Governed

Системот има:

• service ownership;
• on-call;
• runbooks;
• incident management;
• backup;
• restore validation;
• DR;
• capacity planning;
• FinOps;
• post-incident improvement.

Најголемата сила на Evento

Најголемата сила не е една технологија.

Таа е во системската усогласеност:

• одлуките се документирани;
• доменските граници се јасни;
• data ownership е експлицитен;
• ризиците се видливи;
• квалитетот е вграден;
• security е системска;
• operations се дел од дизајнот;
• AI е контролиран;
• трошоците се мерливи;
• архитектурата може постепено да еволуира.

42. Финална контролна листа за студијата на случај

Финалниот checklist служи како брза проверка дали SaaS проектот има целосна професионална основа.

Тој не заменува детален review.

Неговата функција е да покаже дали некоја критична област е целосно заборавена.

Business

• □ Реалниот деловен проблем е валидиран.
• □ Целните корисници се дефинирани.
• □ Главните pain points се документирани.
• □ Вредносната понуда е јасна.
• □ Business value може да се измери.
• □ Scope е контролиран.
• □ Out-of-scope е експлицитно познат.
• □ KPI се дефинирани.
• □ Risk Register постои.

Product

• □ MVP е јасно дефиниран.
• □ MVP го покрива целиот основен customer journey.
• □ Personas се дефинирани.
• □ User journeys се дефинирани.
• □ Epics и user stories постојат.
• □ Acceptance criteria се мерливи.
• □ Roadmap е приоритизиран.
• □ Release strategy постои.
• □ Feature success metrics се дефинирани.

Architecture

• □ System context е јасен.
• □ Bounded contexts се дефинирани.
• □ Context dependencies се познати.
• □ Data ownership е експлицитен.
• □ Domain invariants се дефинирани.
• □ API contracts постојат.
• □ Provider dependencies се изолирани.
• □ Module boundaries се контролирани.
• □ Architecture Decision Register постои.
• □ Scaling strategy е evidence-based.

Security

• □ Authentication model е дефиниран.
• □ Authorization е server-side.
• □ Deny-by-default политика постои.
• □ Tenant isolation е системска.
• □ Cross-tenant negative tests постојат.
• □ Permissions се експлицитни.
• □ MFA постои за privileged users.
• □ Step-up authentication се користи каде што е потребно.
• □ Support access е ограничен и audit-иран.
• □ Production access е least-privilege.
• □ Secrets не се чуваат во source code.
• □ Audit trail постои за критичните операции.

Financial

• □ Money model користи minor units.
• □ Currency е експлицитна.
• □ Payment success page не се користи како authoritative confirmation.
• □ Webhooks се криптографски верификувани.
• □ Idempotency е имплементирана.
• □ Duplicate provider events не создаваат duplicate financial effects.
• □ Ledger постои.
• □ Ledger е append-only.
• □ Refund lifecycle е дефиниран.
• □ Chargeback lifecycle е дефиниран.
• □ Reconciliation постои.
• □ Финансиските операции се audit-ready.

Communication

• □ Communication е посебен домен.
• □ Transactional и marketing комуникацијата се разделени.
• □ Security notifications имаат висок приоритет.
• □ Templates се верзионирани.
• □ Provider adapter постои.
• □ Retry policy е контролирана.
• □ Suppression registry постои.
• □ Delivery events се следат.

AI

• □ Централен AI Gateway постои.
• □ AI feature contracts се дефинирани.
• □ Prompt-ите се верзионирани.
• □ Structured output се валидира.
• □ Фактите се проверуваат кога е потребно.
• □ Permission-aware grounding постои.
• □ Tenant boundaries се почитуваат.
• □ Human approval постои за чувствителни операции.
• □ Golden dataset постои.
• □ Evaluation pipeline е активна.
• □ Cost budgets постојат.
• □ Fallback постои.
• □ Kill switch постои.
• □ Core flow функционира без AI.

Quality

• □ Risk-based test strategy постои.
• □ P0 test suites се дефинирани.
• □ P0 suites мора да поминат пред release.
• □ Integration tests користат production-like dependencies каде што е важно.
• □ Contract tests постојат.
• □ Tenant isolation suite е release gate.
• □ Payment concurrency е тестирана.
• □ Performance е измерен.
• □ Peak-load scenario е тестиран.
• □ Accessibility е проверена.
• □ AI evaluation е дел од quality process.

Delivery

• □ Branch protection постои.
• □ Pull Request review е задолжителен.
• □ CI е автоматизиран.
• □ Quality gates се автоматизирани.
• □ Deployment artifacts се immutable.
• □ Staging е production-like.
• □ Feature flags постојат за ризични releases.
• □ Canary release е поддржан.
• □ Database migrations се backward compatible каде што е потребно.
• □ Rollback е реално тестиран.

Operations

• □ Service Catalog постои.
• □ Секој критичен service има owner.
• □ Criticality tiers се дефинирани.
• □ SLI се дефинирани.
• □ SLO се дефинирани.
• □ Error budgets се активни.
• □ Dashboards постојат.
• □ Alerts се actionable.
• □ Runbooks постојат.
• □ On-call модел е дефиниран.
• □ Capacity model постои.
• □ Headroom е познат.
• □ Autoscaling ги почитува downstream limits.
• □ Graceful degradation е имплементирана.
• □ Load shedding приоритетите се дефинирани.
• □ Backup е автоматизиран.
• □ Restore е реално тестиран.
• □ RTO и RPO се дефинирани и измерени.
• □ Disaster Recovery plan постои.
• □ Game Day е изведен.
• □ Incident process е дефиниран.
• □ Post-Incident Review процес постои.

FinOps

• □ Infrastructure cost е видлив.
• □ Provider cost е видлив.
• □ Cost-to-serve може да се пресмета.
• □ AI spend се следи.
• □ Cost per tenant е видлив каде што е практично.
• □ Cost per feature е видлив каде што е важно.
• □ Budget alerts постојат.
• □ Scaling decisions го земаат предвид cost impact-от.

Governance

• □ Definition of Ready постои.
• □ Definition of Done постои.
• □ Production Readiness Review постои.
• □ Architecture Review процес постои.
• □ Security Review процес постои.
• □ Change Management постои.
• □ ADR governance постои.
• □ Risk review cadence постои.

Финална проверка

Ако значителен број од овие ставки немаат јасен одговор, проектот можеби има функционален software product, но сè уште нема целосна production foundation.

43. Последна лекција од Evento

Најважната лекција од оваа студија на случај не е:

• користи Laravel;
• користи Vue;
• користи PostgreSQL;
• користи Redis;
• користи Docker;
• користи AI Gateway;
• користи Modular Monolith.

Сите тие се технологии или архитектонски избори што можат да бидат правилни во еден контекст и погрешни во друг.

Најважната лекција е:

Технички одличен систем може да биде деловен неуспех.

Одличен product concept може да пропадне поради лоши production operations.

Сигурна архитектура може да стане економски неодржлива ако нема cost governance.

Моќна AI функција може да создаде повеќе ризик отколку вредност ако нема контрола.

Добар user experience не може да го компензира погрешниот financial model.

Добро напишан код не може да ја поправи нејасната data ownership.

Вредноста доаѓа од целината.

Evento започна како едноставна идеја

Почетната идеја можеше да се опише со неколку зборови:

Но кога идејата ја разгледавме како вистински production SaaS, зад тие неколку зборови се појавија:

• корисници;
• организации;
• permissions;
• регистрации;
• капацитет;
• плаќања;
• билети;
• check-in;
• комуникација;
• analytics;
• AI;
• security;
• audit;
• infrastructure;
• testing;
• deployment;
• reliability;
• disaster recovery;
• cost;
• operations;
• луѓе и одговорности.

Токму тоа е разликата меѓу demo и production system.

Demo и Production System

Demo покажува дека нешто може да работи.

Production system докажува дека организацијата може да преземе одговорност за тоа што работи.

Како да го користиш Evento Blueprint

Не треба слепо да ги копираш функциите на Evento во следниот SaaS проект.

Наместо тоа, копирај го процесот.

За сопствениот проект подготви:

• Discovery;
• Business Process Map;
• BRD;
• PRD;
• Personas;
• User Journeys;
• MVP Scope;
• Roadmap;
• Bounded Contexts;
• Domain Model;
• Data Ownership;
• API Contracts;
• Security Model;
• Payment Model ако постојат плаќања;
• Communication Model;
• AI Policy ако се користи AI;
• Test Strategy;
• Deployment Model;
• SLO;
• Scaling Plan;
• Risk Register;
• ADR Register;
• Production Operations Model.

Потоа постави го најтешкото прашање

Замисли дека утре истиот проект истовремено го разгледуваат:

• клиент;
• Product Manager;
• инвеститор;
• Solution Architect;
• engineering team;
• security auditor;
• Finance;
• Operations тим.

Дали сите тие ќе видат една иста, логична и проверлива слика за системот?

Дали клиентот може да ја разбере вредноста?

Дали Product тимот може да објасни зошто scope-от изгледа така?

Дали инженерот знае каде треба да ја имплементира новата capability?

Дали Security знае каде се trust boundaries?

Дали Finance може да ја следи финансиската вистина?

Дали Operations знае што ќе направи ако сервисот падне?

Дали инвеститорот може да разбере како системот ќе расте без трошоците и комплексноста да излезат од контрола?

Ако одговорот на овие прашања е „да“, тогаш проектот има професионална основа.

Последниот системски модел

Последниот чекор не е Production.

Последниот чекор е Evolution.

Затоа што добар SaaS систем никогаш не е навистина „готов“.

Тој постојано учи од:

• корисниците;
• production metrics;
• incidents;
• финансиските резултати;
• security findings;
• market changes;
• нови технологии.

Но тоа учење не треба да создава хаос.

Треба да влегува назад во истиот контролиран циклус: