How do you evolve your microservices architecture without compromising compatibility?

Don't ignore the importance of API governance when developing new API contracts. Ensure that all properties have consistent naming conventions, purpose, formatting, and data types. Exposing a non-standard property violates the principle of least surprise and is a maintenance problem waiting to happen

By decoupling, we can actually enhance business functionality. By decoupling the components, you can more easily make changes to a particular back-end application, knowing that it won’t impact another part of the overall system. The ability to adapt individual services for different contexts without having to re-code the entire module from the global package. With microservices, we definitely embrace this flexibility to make a change on our application. Dividing up different services shape the business and planning perspectives better. For instance, if your software has features for both InvoiceService and ShippingService, your developers and product managers should be able to make improvements to one without disrupting the other.

The purpose and domain of the micro service should be clearly identified and established. Upon that domain and purpose definition the interfaces and API contract should clearly follow the purpose and not extend, service or implement business logic that does not belong to its domain. Following this simple rule will make sure to avoid tight coupling and will at least set a clear base to a path for an evolutionary approach.

Defining contracts plays the key role for backward compatibility. In terms of OOP, they are well-defined Interfaces (following SOLID principle)

Use versioning for the APIs, this allows us to introduce changes or new features without disrupting existing clients. Ensure that new versions of the services are backward compatible, implement feature flags to manage the deployments and to control the ongoing dev work, keep the service decoupled and encapsulate changes within a service, implement robust monitoring and logging to quickly detect address issues that may arise from new changes.

Introduce a new version of your API as a last resort. Each new version increases your maintenance burden by introducing yet another instance of your code that requires updates, testing, and operational support. Instead, favor backward compatibility whenever possible. It is preferable to add new optional properties than to modify properties that are in active use. When a new version is required, set clear expectations with your users when it comes to the retirement of actively used APIs. Optimize the developer experience of your API consumers with clear Open API specifications, release notes, and personalized notifications based on usage metrics.

There can be various types of consumers: external services, internal frontend services, or internal micro-services. It's important to have an identifier in your APIs to determine which service is making the call. This helps deprecation processes for both APIs and services.Review recent data to identify which services access specific endpoints. It's possible that some services may have cached the response and after making changes in your services, it may impact the contract. Minimize or avoid breaking changes like removing or renaming fields, changing data types, or altering endpoints.Introduced a new version in case of braking changes. Test for backward compatibility with existing clients and forward compatibility with new ones.

It is essential to have backward compatibility, but maintaining this compatibility for too long can impact new features. One strategy would be to maintain an old version and a new one, and gradually migrate so that the impact will be low.

Adopting an external schema registry like confluent avro schema registry can help with controlling compatibility mode of different schemas.

Start by designing your APIs and data contracts with versioning in mind. For backward compatibility, ensure that any changes, such as adding new fields or endpoints, don't break existing clients, can be done by making additive modifications. For forward compatibility, structure your services to gracefully handle unknown fields or unexpected data. Use feature toggles to control the release of new features, enabling gradual adoption and rollback if needed. Rigorous testing across different versions ensures that changes do not disrupt the overall system.

Monitoring is also essential to track the backward compatible services usage. Maintaining backward compatibility without notifying the consumers to upgrade might cause issues in the long run. There consumers should stop using the older versions of services at some point and tracking would be good way to measure it.

One approach for this in my experience of creating Kafka-based microservices, using Kafka for event-driven communication and Avro for schema management allows for independent schema evolution and ensures backward compatibility. Kafka's distributed nature supports real-time data streaming, while Avro's schema registry manages data structures seamlessly. This combination enhances flexibility, scalability, and resilience in your microservices architecture, enabling you to adapt to changing business needs and user feedback effectively.

It is also worth considering to think about microservices in a similar manner as you do source code. Refactoring should be an option as the most challenging part of microservices is getting the right domain encapsulated in a service. You may find you created more services that needed or vice versa and having the flexibility to combine or break apart services is a key aspect of maintaining a healthy application.

Remember, evolving your microservices architecture is an ongoing process that requires careful planning, communication, and collaboration. By defining clear contracts, ensuring backward and forward compatibility, implementing comprehensive testing and monitoring, adopting an evolutionary approach, and considering additional factors, you can successfully evolve your microservices architecture while maintaining compatibility and minimizing disruption to your system and its consumers.

Don't couple the outside world to your database schema! Introduce data transfer objects (DTOs) for your APIs, which are standardized representations of your data captured by an OpenAPI specification. Simplify the transformation process by adopting mapping tools, which can aggregate multiple data sources to form one meaningful DTO for your end-users.

Semantic Versioning & Feature Flags: Adhere to Semantic Versioning (SemVer) when developing microservices. This guarantees backward compatibility of changes. Major version increments signify significant changes, patches represent backwards-compatible bug fixes, and minor versions represent feature additions that are compatible with previous versions. Use feature flags to turn on and off new features. This enables you to roll out new features gradually, first to a selection of users or for internal testing, and then to the entire user base. Additionally, feature flags let you rapidly undo modifications in case unanticipated problems occur.

As I’ve built out the modern application architecture, I’ve noted that you will likely need to support more than one language. I wasn’t sure whether to put this here or under #1, but this is about standardizing an approach to exchanging messages between applications. I’ve got a little bit of advice in this regard. While the common approach is “build an API”, many know this to be an unwieldly approach. Invest in a good message broker (RabbitMQ is a solid choice, I’m currently looking at a SaaS one called Memphis.dev) because this is a better rendezvous point than an API. The broker will allow you to exchange JSON messages (or really any kind of message) between systems, and avoid the need to write a new API for every integration.

Add API versioning to enable various versions coexist and hence offer a seamless transition. Use feature toggles to retain the present functionality while quickly adding more features. Test extensively including contract testing to ensure sure modifications do not disturb interactions between services. Plan to phase down obsolete capacity and provide effective change communication to all those affected.