From Legacy to Event-Driven Architecture
Starting point
The client's order handling, inventory flows, and WMS systems were tightly coupled to Oracle databases and PostNord integrations. Every change carried cascading risk: an update in one system could break flows in three others.
Integrations were handled manually and the deployment cycle was limited to once per month. Incident frequency was high, and the team spent more time on firefighting than on new delivery.
The situation slowed both e-commerce and store operations. The client needed modernization that could be carried out incrementally without shutting down ongoing business.
My contribution
- .NET microservices with DDD and event sourcing: Broke up the legacy monolith into domain-specific services with clear aggregates and event-driven flows. Each service could be deployed and scaled independently.
- Azure/Kubernetes with Terraform IaC: All infrastructure defined as code. Reproducible environments, automated deployments, and consistent configuration between staging and production.
- Cosmos DB, Service Bus, Event Grid, and Kafka: The right tool for each integration. Service Bus for commands, Event Grid for notifications, Kafka for high-capacity streams, and Cosmos DB for domain data.
- Grafana observability: End-to-end monitoring across all services. The team could identify and fix problems before they affected end users.
Measurable impact
Deploy frequency
↑ 1100%
Incidents
↓ 88%
Lead time
↓ 81%
Availability
↑ 2.8pp
Outcome
Deploy frequency increased from once per month to three times per week. Incidents decreased by 88%, and lead time went from three weeks to four days.
The new event-driven architecture eliminated cascading risks and helped the client respond faster to seasonal peaks and market changes. The team could focus on new delivery instead of handling system failures.