7 Designing for robustness

 

This chapter covers

  • Communicating robustly between microservices
  • Letting the calling side take responsibility for robustness in the face of failure
  • Rolling back versus rolling forward
  • Implementing robust communication

This chapter introduces strategies for making a system of microservices robust in the face of failures. In general, whenever one microservice communicates with another, the communication may fail. In this chapter, you’ll learn about and implement some patterns for dealing with such failures. The strategies are fairly simple, but they’ll make the overall system much more robust.

Failures and errors

I’ll distinguish between the terms failure and error. A failure happens when something goes wrong in the system and the issue is caused by something outside the system. Some typical sources of failures are as follows:

  • Lost network packets cause communication to fail.

  • Lost connections cause communication to fail.

  • Hardware failures cause microservices to fail.

An error happens when the system can’t serve its users properly. Some typical examples of errors are these:

  • A user sees an error page.

  • The system hangs and never responds to a user action.

  • The system gives back the wrong response to a user action.

7.1 Expect failures

7.1.1 Keeping good logs

7.1.2 Using trace IDs

7.1.3 Rolling forward vs. rolling backward

7.1.4 Don’t propagate failures

7.2 The client side’s responsibility for robustness

7.2.1 Robustness pattern: Retry

7.2.2 Robustness pattern: Circuit breaker

7.3 Implementing robustness patterns

7.3.4 Logging all unhandled exceptions