Microservices architecture promises scalability, independent deployability, and technology flexibility. But these benefits come with significant complexity. Having worked on microservices at Oracle, Walmart, and other companies, I've seen which patterns actually deliver value in production — and which ones cause more headaches than they solve.
A single entry point for all clients. The gateway handles cross-cutting concerns like authentication, rate limiting, SSL termination, and request routing. At Walmart, the order management APIs all went through a gateway that handled Single Sign-On (SSO) before requests hit the business logic layer.
Tools: AWS API Gateway, Kong, Spring Cloud Gateway
When a downstream service fails, you don't want every request to wait for the timeout — especially under high load. Circuit breakers detect failures and short-circuit requests to the failing service, returning fallback responses instead. At OCI, circuit breakers at the load balancer layer prevented cascading failures across the fleet.
Tools: Resilience4j, Hystrix (deprecated but widely used)
Distributed transactions using 2PC (Two-Phase Commit) are slow and brittle. The Saga pattern breaks a transaction into a sequence of local transactions, each publishing events to trigger the next step. Compensation transactions handle rollbacks.
At Walmart's Order Management System, placing an order involved inventory reservation, payment processing, and fulfillment — coordinated via the Saga pattern using Kafka events.
Synchronous REST calls between services create tight coupling and reduce availability. Async event-driven communication via message brokers (Kafka, SQS) decouples services. Services publish events; interested services consume them. This also enables the Disaster Recovery replay pattern — exactly what I built at Walmart to replay e-commerce orders at scale.
When migrating from a monolith to microservices, you rarely get the luxury of a complete rewrite. The Strangler Fig pattern incrementally replaces parts of the monolith by routing specific functionality to new microservices while the old code continues to serve other traffic. This is how we handled the Walmart Canada market migration.
With dozens of services, you cannot debug by reading logs on a single machine. You need:
Microservices are not a default choice — they're a trade-off. Start with a well-structured monolith and extract services when you hit clear scaling or team-boundary pain points. When you do adopt microservices, invest heavily in observability, event-driven communication, and resilience patterns from day one.
Have thoughts or questions? Reach out at tiwarisudhir059@gmail.com or connect on LinkedIn.