Key Parameters to Define Your Microservices Strategy – Part 2

Illya Lovell continues to explain how microservices give you the freedom to innovate with agility.

Organizations are increasingly embracing microservices to build robust, scalable, and durable business applications that deliver memorable customer experiences. In continuing his blog, Ilya Lovell shares three more important factors that will help you build a well-rounded microservice strategy.


A surprisingly large percentage of microservices implementations fail, at least on the first attempt. One of the contributing factors is the compounding introduction of unacceptable latency as the service mesh expands. 

Through microservices, you can undoubtedly gain flexibility, reliability, and speed; however, this will come at the cost of increased resource usage, often leaving your application relatively unresponsive. There will always be tradeoffs: the more flexible your microservices architecture is, the higher the performance costs. 

Here are a few relevant approaches to managing failure and performance:

  • Leverage failover caching, self-healing, retry logic (ensuring you have handled idempotency), health-check/load balancing, circuit breakers, and rate limiters/load shedding to ensure your microservices fail fast and independently. 
  • Design for communication failures as an everyday occurrence. This is because distributed systems provide no assurances that the microservice you want to invoke will be running, that the network is available, or that a response will even be returned. The best approach is to use messages (asynchronously) and event-driven architecture.
  • Improve your microservices application’s resilience with Chaos Engineering – a disciplined approach to identifying failures before they become outages. 
  • Ensure all the team members proactively discover vulnerabilities and continuously apply lessons from failure. 


Shift your thinking and language from a sequence of request/reply interactions to asking “what events should my service process?” and “what events will my service emit?” 

Next, move from orchestration to choreography (Saga Pattern) for service interaction. Let us look at some of the transformative benefits of adopting choreography:

  • Less service coupling
  • More straightforward services with no requirement for complex error handling of downstream services or network failures
  • Less developer overhead to add new services, including increased agility as teams are more independent 
  • Easier fine-grained scaling, resulting in more efficient use of server resources

There is, however, the negative side effect of state consistency if event state changes are not processed immediately. To overcome this effect, one must embrace the concept of “eventual consistency.” This is where we acknowledge that consistency will occur in the future, and we accept that things will be out of sync for a slice of time. 

The messaging platform’s responsibility is to ensure that these change events are never lost before being handled by the relevant service(s) and acknowledged. Command Query Responsibility Segregation (CQRS) pattern can deliver significant benefits by allowing us to leverage event sourcing for handling atomic operations in separate databases. This accelerates the read operations as the load is distributed between the insert and read services. 

Messaging brokers such as Apache Kafka can help coordinate asynchronous communication between microservices. They are super fast, fault-tolerant, and scalable. By retaining data for a configured amount of time, they give you the option to rewind and replay events if required. In Kafka’s case, data can be replicated across a cluster of servers for fault tolerance, including geolocation support. There is also a strong guarantee that messages will be received in the chronological order in which they were published.

Event-Driven Architectures may appear complex initially, but they are the future of many microservices and IT roadmaps. 


With the focus on back-end domain services, the front end is often neglected and ends up becoming its own monolith. Micro frontends help tackle complex, modern web development. Micro frontends are more straightforward, smaller chunks that can be developed, tested, and deployed independently while still appearing to users as a singular and connected experience. 

  • Micro frontends carry forward similar development practices and benefits of the microservices architecture. 
  • They enable minor incremental updates that can be delivered through to production without impacting the broader UI or involving other teams. 
  • Micro frontends allow more rapid user experience improvements as the dependencies and bottlenecks are disbanded in favor of a simpler, decoupled codebase. 

There are, of course, tradeoffs to consider before tackling this approach to frontend development. 

  • Micro-frontends inevitably lead to more management elements such as repositories, servers, build and deployment pipelines.  
  • Therefore, you must assess whether you have enough automation to manage the additional components’ testing and deployment. 
  • You should also consider how you will ensure quality, consistency, and governance across independent buckets of frontend codebases.

Redefine Application Development with Microservices

Many organizations are well underway in their adoption and implementation of microservices. Unfortunately, a high percentage of implementations fail. This ends up creating unmanageable, monolithic services with issues around latency, monitoring, logging, and security, to name a few. The key parameters we explored in this post will help you lay some solid foundations to step forward and define a successful microservices strategy.

At Cognizant Softvision, we are digitally native and, by extension, cloud-native.  Thus, microservice design and development are part of our DNA, and we have been designing distributed systems for decades. 


For more insights on Microservices, read our blogs: