Skip to main content

Resilient Consumers

Context​

Microservices are being adopted and are being deployed independently. The APIs are kept backward compatible as far as possible. There is a need to make changes to microservice API.

Problem​

  • Breaking API changes influence consuming microservices.
    • The system becomes unstable and/or release coordination is required to introduce breaking API changes.

Solution​

Implement consumers in a resilient way that can deal with minor API changes.

For example, make sure to accept or ignore additional fields when receiving a message. If you take this concept one step further, you can use wild cards or similar techniques in data keys to allow for minor adjustments in the messages sent without breaking the consumer.

Still, there are types of changes that cannot be handled by a resilient consumer that require further techniques. We recommend to discover these incompatibilities via consumer-driven contracts tests and use API version if necessary.

Maturity​

More data required (only 3 sources).

Sources of Evidence​

L3:

  • Context: service contracts are critical
  • Versioning
    • can man deployment even more complex
    • usually not recommended
  • Avoid versioning
    • Tolerant reader design pattern

L12:

  • same as gs3

L32:

  • Robustness principle for code interacting with other services
    • be conservative in what you send, be liberal in what you accept from others
  • Example
    • service returns 2 fields
    • other 5 services use that service
    • => ignore extra fields as long as 2 fields are present
    • 6th service joins consumers, requires new field => able to add new field without breaking other consumers
  • => give producing service leeway to make certain contract changes without breaking compatibility

LM43:

  • Context: SLR findings about microservices in DevOps
  • Table 10: lists the tolerant reader pattern