A few years ago, i worked on a payment processing system for a high street bank. The system, in its first stage of evolution, would receive a file full of payme

A few years ago, i worked on a payment processing system for a high street bank. The system, in its first stage of evolution, would receive a file full of payment instructions, parse each one, validate it, then pass it on to a gateway in a special binary format. An architect had decided we should build this as microservices, coupled by message queues. There was one microservice which split the file into records and parsed each one, one which validated each one, and one which handed off to the gateway. In the first demo of the system, it took half an hour to process a file with a few thousand instructions in it. This was a ludicrous amount of time: it really should have been done in seconds. The team met, and one of the senior developers pronounced the solution: since this was a microservice system, we would simply split one of the microservices in two, so we could scale out the amount of hardware we were using. The service selected was the first: rather than splitting and parsing the file in one pass, a first microservice would split the file into chunks, and pass each one onto a second microservice, which would parse them. I asked where we thought the problem was, why we thought splitting a service would help, how we would measure the improvement, and, moreover, why we thought that adding a network hop would make things faster rather than slower. My questions were rejected as self-evidently unnecessary: it is well-known that you can improve the performance of a microservice system by scaling out. The service was split. There was another demo. It was just as slow as before. The project was removed from that team, and transferred to a new team under my leadership. (this is a true story; the one fact omitted for the sake of drama is that the transfer of the project wasn't due to the embarrassing demo, it was purely down to staffing and logistics)