We are currently hitting a wall with our monolithic .NET application. Deployment cycles are taking forever, and a single bug in the payment module crashes the entire storefront. We want to move to microservices but are terrified of data corruption during the transition. Should we focus on a "Big Bang" migration or a gradual approach? What are the industry-standard patterns for splitting a shared database?
3 answers
The "Big Bang" approach is almost always a recipe for disaster in production environments. Based on my experience leading migrations in late 2023, the Strangler Fig pattern is the safest bet. You essentially build new microservices around the edges of the monolith and use an API Gateway to route traffic. For the database, avoid the temptation to let services share a schema. You need to implement the Database-per-Service pattern, even if it means temporary data duplication. Use CDC (Change Data Capture) tools to keep the old and new databases in sync during the interim period to ensure zero data loss.
How do you handle the increased latency that comes with all these internal network calls once you've split the services? Doesn't moving from in-memory calls to REST or gRPC significantly slow down the overall user experience if not managed properly?
Domain-Driven Design (DDD) is the only way to find your service boundaries. If you don't define your Bounded Contexts first, you'll just end up with a "distributed monolith" which is even worse.
Emily is spot on. Without clear boundaries defined by the business logic, your services will be too tightly coupled, and you'll find yourself deploying three services just to update one feature.
Mark, that’s a valid concern. You mitigate this by using asynchronous communication for non-blocking tasks and implementing an API Gateway for request aggregation. Instead of the client making ten calls to ten services, the gateway does it internally and returns a single response, which keeps the perceived latency low for the end user.