A Consolidated Deployment Edition of a Microservice Core-Banking Platform: Composing Services by Reference into Three Hosts
Microservices give teams independent deployment and scaling, but each deployed service also reserves compute and adds operational work. This paper examines a second deployment edition of a multi-tenant .NET core-banking platform. The existing edition runs as nine AWS ECS Fargate tasks; the alternative composes the five API services by project reference into one API host, alongside a consumer host and a background host. The service code remains in its original repositories, and both editions continue to be built from the same commits. We describe the composition mechanism, module manifest, start-up checks, request handling and configuration precedence, then compare the editions in an emulation of the AWS deployment. The composed edition exposes all 844 declared operations. Across 47 financial workload cases, both editions produced the same observed outcomes and matching ledgers. In read probes across five principal types, 230 of 231 endpoint results matched; the remaining difference was associated with the emulated load balancer. Eleven cross-tenant and write-authorisation cases also produced the expected outcomes in both editions. In the emulation, the composed edition delivered 2.3 times the read throughput and used less than half the memory. Estimated service-task compute at list prices was 11-24% lower, excluding the shared gateway, load balancer, data stores and other operating costs. The consolidation also enlarges the failure domain: one API-host crash takes all five modules offline. Of 16 injected faults, the edition's checks detected 10, behavioural tests detected five additional faults, and one fault escaped both. These findings concern one platform and an emulated deployment that mirrors its topology, task sizes and configuration; they are not production-AWS measurements.