Microservices that earn their complexity
Boundaries, resilience and migration paths from real enterprise programmes. By Sanjeev Kumar, Application Architect.
Split along change and ownership
Service boundaries should follow business capability and release cadence, not class diagrams. If two modules always change together and share a database transaction, they are not ready to be separate deployables. Domain-driven language helps name the seams; operational ownership decides whether the split is honest.
Strangler-fig over big-bang
Legacy cores in banking and insurance rarely tolerate a rewrite. An API façade, incremental extraction and dual-run verification reduce risk. That approach underpins the transaction platform modernisation write-up and pairs with event-driven integration so new services do not recreate synchronous mesh sprawl.
Resilience is design, not a library checkbox
Timeouts, retries with jitter, circuit breakers, bulkheads and back-pressure belong in the contract between services. Retries without idempotency create duplicate money movements. Prefer asynchronous workflows when the business allows eventual consistency; when it does not, make the consistency boundary explicit.
Platform expectations
CI/CD, container orchestration, secrets, service identity (mTLS / JWT) and shared observability are table stakes. On regulated platforms that includes mTLS for service-to-service traffic and clear RBAC on privileged operations — as on the financial platform modernisation. See cloud architecture, Kubernetes and Java architecture for implementation depth.