From N-Tier Architecture to Microservices and Agents

Transcript

1. CND Romania 2026 • Bucharest • 18-19 May From N-Tier Architecture to Microservices and Agents
2. My Perspective & Purpose 18-19 May Speaker spotlight Adelina Stanciu Senior Engineering Manager Finastra
3. Agenda • Introduction • Why the architecture needed to evolve • Case Study Overview • Evolution: N-Tier->Microservices • Evolution: Microservices->Agents • Governance, Context Aggregation and Reconciliation • Outcomes & Lessons Learned • Q&A
4. Why the Architecture Needed to Evolve
5. Why the architecture had to evolve 01 Data Inconsistency Data inconsistency across layers and services leads to conflicting states and unreliable outputs 02 Tight Coupling Small changes can break multiple parts of the system due to deep interdependencies between layers 03 Slow Development Too many dependencies slow teams down, making it harder to iterate quickly and deliver value 04 Large, High-Risk Releases Releases require complex coordination across all layers, increasing the blast radius of every deployment 05 Operational Complexity Increased operational overhead as the system grows, making monitoring, debugging, and maintenance harder 06 Scalability Issues Scaling requires scaling the entire stack rather than individual components, wasting resources and limiting flexibility
6. Case Study Overview
7. The Starting Point: Infrastructure Overview
8. Architecture Layers Presentation UI, Admin Portals Application Core Business Logic Domain Services Pricing, Product Preview Microservices; capabilities Automation Layer Setup Service, Governance Agents, Bridge Integration ACL → API Connectivity, external Data Layer SQL, Service DBs
9. Database strategy Core owns Azure SQL (Azure Managed) Microservices own independent Service DBs Legacy interactions isolated in Oracle via ACL No shared DBs across domains No cross-service database joins
10. The Starting Point: N-Tier Architecture
11. The Starting Point: N-Tier Architecture - Azure
12. The Starting Point: N-Tier Architecture – API
13. Data flow 1. User opens the web store in browser. 2. User performs various operations to place an order. 3. The API hosted on application server executes business logic. The API will read/write the data to the database hosted on database server. 4. API Response is sent back to the application. 5. The Web App executes business logic and interacts with the SQL database. 6. User is informed the order is placed with an order confirmation page and by mail.
14. Evolution Path: N-Tier → Microservices
15. How to identify boundaries 1 Identifying High-Cohesion, Low-Coupling Areas Group functionality that changes together and minimize dependencies between groups to define natural service boundaries 2 Mapping Business Capabilities Align service boundaries with what the business does, not how the code is organized today 3 Pain-Point-Driven Boundaries Draw boundaries around the slowest-moving parts and the most change-prone logic to isolate risk and accelerate iteration 4 Data Ownership as a Boundary Driver Each service owns its data exclusively, eliminating shared databases and enforcing clear contracts between boundaries
16. Bounded Contexts & Ownership The Core Constraints Core Azure SQL Database Primary Business State Pricing Service Dedicated Pricing DB Rules & Calculations Product Preview Dedicated Preview DB Read-Optimized Models Database-per-service: Strictly enforced. No shared data access.
17. Microservices Design Pricing Service Product Preview Complex pricing rule engine High-performance calculations Separate Runtime Read-heavy performance tuning UI-focused data projection Decoupled from Core writes → → → → → →
18. Transition to Microservices
19. Microservices architecture
20. Evolution: Microservices->Agents
21. Transition to Agents
22. Agents architecture
23. Agents and Deployment model
24. Governance, Context Aggregation & Reconciliation Agents
25. Data Aggregation Agent 4 Send Collects, combines, checks and sends clean pricing data forward. Pricing Sources Oracle DBs DATA AGGREGATION AGENT Turns messy input into usable data 1 Collect Get data 2 Combine One format 3 Check Find issues Clean data Governance Layer Rules • approval • audit What it also does Removes repeats Same price is not counted twice Flags gaps Missing or delayed data is flagged Tracks source Each record can be traced later
26. Governance & Reconciliation Decision Logic Turns clean pricing data into trusted pricing decisions before activation. 1 ✓ Validate Checks pricing data against business rules 2 ⇄ Reconcile Resolves conflicts across sources 3 ✓ Approve Only trusted data moves forward 4 API Activate Sends approved pricing data to the Pricing API ▰ Pricing API ! Manual Review Triggered by validation failures or conflicts ✦ Also Handles ! Exception Handling Flags records for review ≡ Priority Rules Chooses the best source □ Audit Trail Tracks what changed and why
27. Legacy Integration (ACL Pattern) DB Legacy Systems Oracle schemas / legacy data models </> Modern Domain Core domain API services ◇ Anti-Corruption Layer ⇄ Translation Bidirectional mapping between Core and API ▦ Isolation No direct coupling to Oracle schemas ↻ Evolution Legacy can change without breaking services
28. Dynamic Flow: Pricing Governance Pricing Data Sources Aggregation Normalization Agent Governance Validation Agent Authorized Update Service DB Validated State
29. Dynamic Flow: Request Path User Entry UI Request Core Logic Core Orchestration Domain Query Pricing, Product Preview Calls UI Response Aggregated Response Delivery
30. Risks & Trade-offs Performance Core bottleneck potential Pricing runtime dependency Governance pipeline latency Systemic Complexity Data consistency challenges Legacy dependency fragility Multi-agent coordination
31. Risk Assessment Risk Factor Impact Likelihood Core Bottleneck High Medium Pricing Latency High Medium Data Consistency High Medium Legacy Dependency High High Agent Complexity Medium High
32. Risk Mitigation Strategy Enforce API-only access. Domain Integrity Correlation IDs and tracing across all layers. Observability Circuit breakers for all legacy integrations. Resiliency
33. Architecture Decisions (ADR Summary) Decision Rationale No API Gateway Controlled internal consumption; lower initial complexity. DB-per-Service Enables independent scaling and ownership. Sequential Pipeline with buffer Controlled data flow and upstream isolation ACL Implementation Protects domain evolution from legacy constraints.
34. Outcomes & Lessons Learned
35. Outcomes & Lessons Learned Outcomes Lessons Learned ➢ Clearer service ownership ➢ Independent scaling ➢ Lower legacy coupling via ACL ➢ Stronger data governance ➢ Performance improvements ➢ Foundation for future automation ➢ Boundaries follow business capabilities ➢ Data ownership defines independence ➢ Microservices add operational complexity ➢ Use agents for cross-cutting workflows ➢ Design governance early
36. Future Roadmap Evolution Deep extraction of additional Core capabilities Implementation of CQRS for complex read models Specialized Agents for other domains Extract Specific Azure Functions End to End Setup Automation
37. Summary 01 Clear Ownership Boundaries Each service owns its data and logic, eliminating shared databases and reducing cross-team dependencies 02 Scalable Microservices Architecture Independent services scale on their own, enabling faster releases 03 Controlled Governance Pipeline Agents validate, reconcile and approve pricing data before it reaches production 04 Strong Legacy Isolation The ACL pattern shields modern services from legacy schemas, allowing both sides to evolve independently
38. Q&A