CL

Case Study

Platform Modernization

The merger of two distinct platforms, a cloud-based distributed monolith and a desktop-based monolith built for precision, into a unified event-driven microservice architecture on Kubernetes.

Transformation Journey

1

Two Platforms

  • Cloud monolith (bulk processing)
  • Desktop monolith (precision)
  • Separate codebases, no sharing

Divergent systems, duplicated cost

2

Unified Substrate

  • Kubernetes as common foundation
  • Vertical slice architecture
  • Domain-driven decomposition

Single platform direction set

3

Strangler Migration

  • Incremental cutover from both
  • Dual-platform coexistence
  • No client disruption

Migration without downtime

4

Single Orchestrator

  • Pluggable multi-tenant engine
  • Event sourcing for traceability
  • Per-service CI/CD pipelines

One engine for all workloads

5

Unified Platform

  • Bulk + precision, same substrate
  • Independent team deployments
  • Full lineage + observability

Merger complete, platform unified

The Two-Platform Landscape

Platform A

Cloud-Based Monolith

Served large institutional clients with high-volume bulk processing. Cloud-native but architecturally constrained, it was a distributed monolith where scaling required deploying the entire application.

  • High-throughput bulk processing for large institutions
  • Cloud-hosted with limited horizontal scalability
  • Coupled deployments across all functionality
Platform B

Desktop-Based Monolith

Served a different client base of boutique firms and operations requiring precision, data lineage traceability, and small-data workflows. Could not scale horizontally and was constrained by desktop deployment.

  • Precision-focused execution with full lineage traceability
  • Small-data operations for boutique and mid-tier firms
  • Desktop-bound with no horizontal scaling path

The core challenge was not simply migrating a monolith to microservices; it was merging two fundamentally different platforms with distinct processing profiles, client bases, and architectural assumptions into a single system that could excel at both bulk throughput and precise, auditable execution. The resulting platform had to serve the entire industry, from the largest institutions to the smallest operations, with equal visibility and traceability.

Challenge

Two platforms serving the same business domain with incompatible architectures, different client segments, and fundamentally different processing models needed to become one. The combined platform had to handle high-volume bulk executions with the same fidelity as precision small-data workflows while providing unified auditing, presentation, and lineage traceability across all processing profiles.

  • Merging a cloud-based distributed monolith with a desktop-based monolith that could not scale
  • Supporting both high-throughput bulk processing and precision small-data workflows in one architecture
  • Delivering production-grade lineage traceability and auditability for clients of all sizes
  • Serving diverse client needs, both large institutions and boutique firms, without compromising either experience
  • Coordinating the product merger across multiple sub-teams alongside the re-architecture

Strategy

A unified event-driven architecture on Kubernetes where each service owns a complete vertical slice of business capability. The processing orchestrator was designed as a generic, pluggable multi-tenant engine configured through Service Bus subscriptions and ConfigMaps to handle both bulk and precise workflows through the same substrate.

  • Kubernetes as the unified platform foundation for both processing profiles
  • Vertical slice architecture with domain-driven service decomposition
  • Pluggable multi-tenant processing orchestrator configurable for bulk or precision workflows
  • Event-driven architecture for asynchronous, auditable processing pipelines
  • Strangler fig pattern for incremental migration of both platforms
  • Service Bus for reliable message delivery with full event sourcing for traceability
  • Continuous integration and deployment pipelines per service for independent delivery

Tradeoffs Considered

  • Microservices vs monolith: chose vertical slice decomposition for independent team ownership and scalable deployment, accepting distributed system complexity, network latency, and operational overhead in exchange for organizational alignment
  • Kubernetes vs Azure Cloud Services: selected Kubernetes for multi-cloud portability, ecosystem maturity, and community momentum, accepting a steeper operational learning curve and more complex cluster management
  • Strangler fig vs big bang migration: adopted incremental strangler fig pattern to migrate both platforms without disrupting existing clients, accepting an extended transition period with dual-platform maintenance overhead
  • Single generic orchestrator vs two specialized engines: designed a pluggable multi-tenant orchestrator capable of handling both bulk and precision workflows through the same substrate, accepting the risk of over-generalization in exchange for unified operational simplicity
  • Event sourcing with Service Bus vs simpler message queuing: implemented full event sourcing for complete auditability and replay capability, accepting increased storage requirements and event replay complexity compared to a lightweight queue

Results

Successfully consolidated multiple product experiences into a unified platform, enabling a consistent and scalable operating model across diverse client needs.

  • Improved scalability and resource utilization through independently scalable platform capabilities that could adapt to changing demand patterns
  • Established fair and predictable workload processing across tenants of all sizes, improving platform efficiency and customer experience
  • Enhanced transparency, traceability, and auditability of operational data, strengthening customer trust and regulatory readiness
  • Expanded access to enterprise-grade operational insights, enabling organizations of all sizes to benefit from the same level of visibility and accountability
  • Increased delivery velocity by transitioning from infrequent releases to a more continuous and responsive deployment model
  • Reduced deployment risk and improved service availability through modern release and operational practices
  • Eliminated coordination bottlenecks between teams by enabling independent ownership and deployment of platform capabilities
  • Improved operational awareness through comprehensive observability and monitoring across the platform ecosystem
  • Increased organizational agility by enabling teams to respond more quickly to evolving business priorities and customer requirements

Before vs After

Before

Cloud Monolith

  • Quarterly release cycles
  • Coupled deployments across all teams
  • Limited horizontal scaling for specific processing paths
  • No distributed tracing across services
  • Bulk-only processing profile
Before

Desktop Monolith

  • No horizontal scaling capability
  • Desktop deployment constraints
  • Precision-focused but volume-limited
  • No cloud integration or remote access
  • Separate codebase from cloud platform
After

Unified Microservices

  • Weekly release cycles with continuous delivery
  • Independent deployments per service boundary
  • Distributed tracing and centralized observability
  • Bulk and precision processing from a single platform
  • Full data lineage traceability for every client
  • Elastic horizontal scaling for any processing profile
  • Unified auditing and presentation across all workflows