Source for this statement: https://devopedia.org/postel-s-law

Though at first glance this does not seem to be directly related to the topic of isolation, this age-old principle helps to define the core of Microservices.

Let's break the statement down into two parts:

This is what Microservices are all about: focusing on a fixed set of responsibilities and being responsible for communicating with other services. When we say to be conservative in what you send, we are also accepting the fact that we are doing a limited, fixed set of activities in the service. Ideally, one Microservice should be focusing on one task. So, when we say we have a TaxCalculator service or a PhotoUploader service, we know that the service is going to calculate tax or upload a photo, and nothing else. In other words, this is in sync with our Single Responsibility Principle, that is, one service is handling one responsibility. This is a very important concept when it comes to implementing isolation. Let's say we have a service, EmployeeDataUpdateAndPhotoUploader. For some reason, the photo-uploader part is broken (say due to a developer mistake, it goes into a loop or out of memory). Now the photo-uploader part can slow down or break the employee-data-update part as well. So if all I needed was to update the address for an employee, I cannot do it because the photo-uploader code is broken.

Whenever you feel that your service is doing too much work, break it into multiple services. A simple rule is to try to write down the role that the service is playing. If there are too many ands, for example, we are writing that this service does this and this, you know it will be difficult to manage.

Let's look at the other part of the rule.

You cannot control how your service is going to be used, but you can manage the behavior on your end, by keeping a check on which input your service is going to accept. So if your service needs four parameters to work properly, build it in a manner that it can receive three or five parameters. What should our service do in case incorrect input is recieved? Can we somehow manage and convert the input into the required format? If not, we should gracefully send back the required messages. The idea is that your service should never be caught unprepared. Unplanned input can break down your service to get infinite loops or a memory leak situation, where one faulty request is making others suffer.