From Monolith to Microservices: Axis Bank's Lending Platform Journey

At Axis Bank, our Corporate Business Loans platform started as a monolith. As loan volumes grew, we needed to break it into microservices. Here's how we did it without downtime.

The Monolith Challenge

Our original system handled:

• Loan applications and submissions
• Credit scoring and verification
• Approval workflows (multi-level)
• Disbursement processing
• Document management

All in one Spring MVC application with 200K+ lines of code.

Problems:

• Deployments took 30+ minutes
• One bug could bring down the entire system
• Teams blocked each other on releases
• Scaling meant scaling everything

Microservices Strategy

We identified 5 core bounded contexts:

1. Application Service - Loan submissions
2. Credit Service - Scoring and verification
3. Approval Service - Workflow engine
4. Disbursement Service - Payment processing
5. Document Service - PDF generation and storage

Migration Approach

Phase 1: Strangler Fig Pattern

We didn't rewrite everything at once. We:

• Kept the monolith running
• Built new features as microservices
• Gradually migrated existing features
• Maintained a facade layer for compatibility

Phase 2: Data Decomposition

This was the hardest part. We:

• Identified data ownership boundaries
• Created separate databases per service
• Used Saga pattern for distributed transactions
• Implemented eventual consistency where appropriate

Phase 3: Communication Patterns

Services communicate via:

• REST APIs for synchronous calls (e.g., credit checks)
• Events for async workflows (e.g., approval notifications)
• Shared cache (Redis) for reference data

Technical Implementation

Service Template

Each microservice followed this pattern:

@SpringBootApplication
@EnableDiscoveryClient
public class LoanApplicationService {
    public static void main(String[] args) {
        SpringApplication.run(LoanApplicationService.class, args);
    }
}

API Gateway

Used Spring Cloud Gateway for:

• Request routing
• Authentication (OAuth 2.0)
• Rate limiting
• Circuit breaking

Distributed Tracing

Implemented with Spring Cloud Sleuth + Zipkin:

• Track requests across services
• Identify bottlenecks
• Debug distributed transactions

Challenges We Faced

1. Data Consistency: Distributed transactions are hard. We used Saga pattern with compensating transactions.

2. Service Discovery: Services needed to find each other. We used Eureka for service registry.

3. Configuration Management: Centralized config with Spring Cloud Config Server.

4. Monitoring: Added Prometheus + Grafana for metrics, ELK stack for logs.

Results

After migration:

• Deployment time: 30 min → 5 min per service
• System availability: 99.5% → 99.9%
• Team velocity: +50% (teams work independently)
• Scalability: Can now scale services individually

Key Lessons

1. Don't start with microservices - Monoliths aren't evil
2. Define clear boundaries - Domain-driven design helps
3. Observability is critical - You can't debug what you can't see
4. Data migration is the hardest part - Plan it carefully
5. Team organization matters - Conway's Law is real

When to Use Microservices

Use microservices when:

• Teams are large and need independence
• Different parts of the system have different scaling needs
• You need flexibility in technology choices
• Deployment frequency is critical

Stick with monoliths when:

• Team is small (<10 developers)
• Domain boundaries are unclear
• System isn't complex enough to justify overhead
• You're just starting out

---

Thinking about microservices migration? Let's discuss your architecture challenges.