2026-09-14 · 5 min read
Splitting a port logistics platform into eight micro-frontends without splitting the design
How the SCR (Secure Container Release) web platform at T-Mining was restructured into eight independently deployable frontend modules with one shared component library, and what a 60% load-time improvement actually required.
Secure Container Release is a port logistics platform backed by eight backend microservices, and its users need different screens for different roles. I led the frontend architecture as it moved from one large React app to eight independently deployable modules.
Why split at all
Different user groups ship at different cadences. A change for terminals should not require re-testing the carrier flow, and a slow screen for one group should not slow the others. Independent deployment also lets each module be sized for its own traffic.
The shared component library is the architecture
Eight modules built by different hands drift visually within weeks unless the design lives in code they all import. The library owns layout primitives, form controls, tables, and the tokens behind them; a module composes, it does not restyle. That is what kept cross-module layout consistent and made a design change a one-place edit.
Where the 60% came from
- Rendering only what the route needs: modules load their own bundles, so the terminal screen no longer paid for carrier code.
- Memoisation and state discipline on the hot tables, the same work as any React performance pass, but measured per module.
- The v1.5 migration removed legacy layers that every request had been passing through.
Testing across module boundaries
Unit tests do not catch a broken hand-off between modules. Playwright end-to-end suites run the real flows a user takes across them, in a browser, on every change, which is what made independent deploys safe rather than merely possible.
Backend work is part of the job
The same role delivered backend features on the microservices, including transactional MJML email templating, and managed deployments on AWS. A frontend architecture decision that ignores how the services deploy does not survive contact with production.