Martin Kleppmann

for me reliability means fault tolerance primarily so meaning that a system should on the whole continue working even if like a network link is interrupted or a node crashes or something like that so a lot of the book is about techniques that support fault tolerance like replication for example so that's reliability scalability is

one of those terms that gets thrown around a lot and it's sort of so much and it's like fashionable and cool to make things scalable you know because it's it suggests success and millions of users and so that's of course everyone wants things to be scalable because everyone wants success

But this book here tried to take a bit more dispassionate kind of approach and said scalability is just like what mechanisms we have for dealing with changes in load.

If load increases, how can we add computing capacity to a system, for example, so that the system still continues working?

And then the techniques that you use to achieve scalability, well, they are like sharding, for example.

Yeah, I guess because that's the more interesting one.

Like, yes, you can always buy a bigger machine.

And what's interesting about that?

Exactly.

There's just, there's not that much to be said about it.

I mean, there are details of how you scale even on a single machine.

But I think like part of what is become interesting about like

modern cloud services, just backend services in general, is like how they've introduced this idea of horizontal scalability and shared nothing systems.

So we can build systems that are able to cope with very high load, even if the individual components are just fairly cheap commodity machines.

But maybe sort of part of the scalability story, which I wasn't thinking about as much at the time, but started thinking about more recently, is not just scaling up, but scaling down as well.

So actually, how do you run a service in such a way that if it has a very small amount of load, it's really cheap to run it?

That's sort of it.

in a way the same question as how do you continue running a service if it has very high load generally like you just want the the cost and the computing capacity to be roughly proportional to the load that you have and at the low end that means actually being able to scale down to something that is extremely cheap to run and that's like not so necessarily given that's something that is hard with on-premises software for example because like if you've got a machine of

a physical machine that's like a a unit of deployment and yes you could carve it up into two dozen virtual machines and make those small virtual machines but um it still requires like some sort of resource allocation and so so part of what's interesting about some serverless systems for example is actually their ability to scale down and say like okay if you're going to handle just three requests per day that's just fine as well can you tell me about the second edition

When did the idea come about?