Eduvos ITSMA4 / 2026
Designing boundaries between services
Evaluate service boundaries, data ownership and distributed-system trade-offs in a named architecture report spanning three academic scenarios.
SUBMITTED ARCHITECTURE REPORT / DESIGN, NOT DEPLOYMENT
- 01
Client / API gateway
Proposed entry point in the NexaFlow case study
- 02
Business service boundaries
Project, User, Billing and Notification responsibilities
- 03
Independent data ownership
Stores belong to their service, rather than a shared writable database
- 04
Asynchronous work
Proposed events and a message broker for notifications and analytical updates
ENGINEERING PERSPECTIVE
Inside the work
Evaluate service boundaries as an engineering trade-off rather than a default upgrade. The report connects business responsibilities to contracts, data ownership and the operational cost of distributed systems.
- Architecture report / diagrams
- Named coursework analyses three academic migration scenarios.
- Service contracts / messaging
- The report compares API gateways, synchronous calls and asynchronous communication at the design level.
Identify responsibilities
Break down the academic scenario into bounded business concerns.
- Ownership boundaries
- Services need clear business and data responsibilities, not just separate deployment units.
- Distributed failure
- Fault isolation, observability and CI/CD add responsibilities absent from a simple in-process call.
- Monolith trade-offs
- The report also identifies when a monolith is the simpler choice; microservices are not presumed faster or more reliable.
What the demonstration establishes
The diagram is a new explanation of the submitted design. No running services, measured reliability or real client engagement is claimed.
Evidence behind this page
Azhar-named 27-page ITSMA4 report and diagram-generation source; all companies are coursework scenarios.
How it works
Separate business responsibilities and data ownership, compare synchronous APIs with asynchronous messaging, and analyse CI/CD, fault isolation and observability. The report also discusses situations where a monolith is the simpler choice.
Results & recovery
- A complete named report and its diagram-generation source were recovered.
- The new portfolio diagram explains the proposed gateway, business services, independent stores and messaging boundaries.
Technical limitations
No running services, deployment manifests or measured reliability/performance results accompany the report. Its case-study companies are academic scenarios, not employment clients.
What I would improve now
Implement one bounded synthetic scenario, define contracts and failure cases, then measure the operational trade-offs rather than assuming microservices are an improvement.