UI composition
Micro-frontends only where teams are independent. Otherwise a modular monolith frontend.
Why. Micro-frontends add runtime and ops complexity.
Trade-off. Less independence if you choose a single frontend.
Integration and multi-application · Web, mobile and back office
Multi-channel API platform with a portal over several back-end apps
Web, mobile and staff back-office experiences on one API platform. A backend-for-frontend per channel and a micro-frontend portal let several applications look like one product without becoming one codebase.
A reference architecture from EITSAA, not a named client system. Service limits, prices and product features change, so confirm current details before you commit to a design.
- ACSC Essential Eight
- Australian Privacy Principles
- WCAG 2.2 AA
- Australian regions
Architecture
- People and clients
- Network and edge
- Compute and containers
- Security and identity
- Monitoring, audit and analytics
- Request or data flow
- Asynchronous or optional
- Boundary: region, account, network or trust zone
Request and data flow
Each channel reaches the same edge. Static micro-frontend bundles are served from the CDN, API paths route to the platform.
Path-based routing sends customer traffic and staff traffic to different backends-for-frontend, each with its own authentication rules and rate limits.
The customer BFF aggregates calls to the domain services and shapes the response for the screen, so mobile and web make one call instead of five.
The staff BFF applies role checks, bulk operations and audit logging, and calls the same domain services with elevated but scoped permissions.
Components and why they were chosen
| Component | What it does | Why this choice |
|---|---|---|
| Portal shell with micro-frontends (Module Federation, single-spa or web components) | Independent teams ship parts of the UI. | Use only when there are genuinely separate teams. Otherwise one codebase is simpler. |
| Design system and shared components | Consistent look, accessibility and behaviour. | The real glue of a multi-app portal. |
| CDN with WAF | Static assets, routing and protection. | One edge for every channel. |
| Backend-for-frontend services | Per-channel API shaping. | Prevents one API trying to serve every UI badly. |
| Domain services | Own the data and rules. | Reuse across all channels. |
| Identity provider (Entra ID, Cognito) | Shared sign-in and tokens. | Single sign-on across all the apps. |
| API gateway | Policy and versioning. | Stable contracts for mobile apps that cannot be force-updated. |
| Contract tests and visual regression tests | Catch breakage between teams. | Cheaper than finding it in production. |
Design decisions and trade-offs
API shape
BFF per channel.
Why. Each channel gets exactly the data and auth it needs.
Trade-off. More services, and duplicated logic must live in domain services.
Versioning
Additive changes, long-lived versions for mobile.
Why. Old app versions stay in the field for months.
Trade-off. Support burden for old versions.
Identity
OIDC with short-lived tokens and refresh handled in the shell or BFF.
Why. One session across apps.
Trade-off. Token handling must be done carefully.
Well-architected pillars
Security
WAF, OIDC, CSRF protection, per-BFF authorisation and secure storage of tokens on mobile.
Reliability
Timeouts and fallbacks in the BFF, so one slow service does not break the screen.
Performance
Edge caching, aggregation to reduce round trips and bundle splitting.
Cost optimisation
BFF and service compute, CDN transfer and the team cost of multiple deployables.
Operational excellence
Independent pipelines per micro-frontend and service, with consumer-driven contracts.
Sustainability
Shared bundles and caching to reduce bytes.
Network, identity and data
Networking
Only the edge is public. BFFs and services live in private subnets or a private Container Apps environment. Service-to-service calls use mTLS or workload identity.
Identity and least privilege
One identity provider. Customers and staff use different app registrations and policies. Mobile uses authorization code with PKCE. BFFs hold secrets, browsers do not.
Data and encryption
Each service owns its data. Aggregation happens in the BFF at read time, with no shared database across services. Classify fields and filter personal information in the BFF per role.
Security and compliance mapping
| Control | How this design addresses it |
|---|---|
| Restrict administrative privileges | Staff functions behind separate roles and audit. Essential Eight. |
| Accessibility | Shared design system tested to WCAG 2.2 AA. |
| Privacy | Role-based field filtering in the BFF supports APP 11. |
Mappings show how the design supports each control. They are not certifications, and EITSAA does not claim IRAP assessment or compliance for any reference architecture.
Failure modes, targets and scaling
- Target RTOUnder an hour per component with automated rollback
- Target RPOPer service data store policy
- Scaling and limitsEach BFF and service scales independently. Watch downstream concurrency limits.
| Failure mode | Mitigation |
|---|---|
| One micro-frontend breaks the shell | Error boundaries, versioned bundles and a rollback per module. |
| Slow downstream service | Timeouts, partial responses and caching in the BFF. |
| Old mobile app calls a removed endpoint | Deprecation policy, telemetry on versions and forced-update only as a last resort. |
| Inconsistent UI between apps | Design system, visual regression and a design owner. |
Observability and runbooks
- Real user monitoring per micro-frontend.
- Per-route latency and error rate at the BFF.
- Contract test status in the dashboard.
Cost drivers and levers
More deployables mean more pipelines and compute. CDN transfer is small by comparison.
- Consolidate BFFs where channels are similar.
- Cache responses.
- Share infrastructure across services.
Implementation and fit
Phased approach
- Decide whether you need micro-frontends at all.
- Build the shell, design system and the first BFF.
- Move one back-end app behind the platform.
- Retire old channels as the new ones prove themselves.
Anti-patterns to avoid
- Micro-frontends for a team of five.
- A single API serving web, mobile and staff.
- A shared database between services.
- No design system.
When to use it
- Several teams or back-end apps sharing one portal.
- Web, mobile and staff channels with different needs.
When not to
- A single application with one team.
- Where a modular monolith meets the need.
More in integration and multi-application
Master data
Master data management and integration across HR, finance and CRM
Agree who owns each core entity (person, organisation, product, cost centre), publish the golden record to the systems that need it and reconcile the differences before they reach a report or an auditor.
Modernisation
Legacy system modernisation with the strangler fig pattern, APIs and RPA
Replace a legacy system one capability at a time. A routing facade sends each request to the old or new implementation, anti-corruption layers protect the new design and RPA covers the gaps until APIs exist.
Partners
B2B file and EDI exchange with partners and suppliers
Secure, auditable exchange of orders, invoices and reports with partners that still send files: managed SFTP, validation, translation, acknowledgements and monitoring that proves nothing was lost.
Related insights
Discuss this architecture
Tell us your systems, constraints and timeline. We reply within one business day, and the initial conversation is free.