korrents

Martin Kleppmann

@martin-kleppmann · 26 positions · 0 changes of mind

Computer science researcher at Cambridge, author of Designing Data-Intensive Applications, after a decade in industry at his own startups and LinkedIn.

Martin Kleppmann did not write this page.

We collected these quotes from things they published elsewhere, and every quote links to where it was said. They have no account here and have not endorsed this site. Quotes are word for word; the short line under each one is our own restatement, not their wording. Their own site. Is this you? Claim it or ask us to remove it. Or tell us what is wrong here.

  1. Our reading

    Reliability in a data system means fault tolerance above all: the system keeps working when a network link is cut or a node dies.

    Their wordsfor 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.
    spoken · machine transcript hear it at 0:23:17 · all korrents from this recording

    ↗Designing Data-intensive Applications with Martin Kleppmannyoutube.com 1st of 26 in this recording

    Interesting

  3. Our reading

    Scalability is not a property a system has; it is the set of mechanisms it has for coping with a change in load.

    Their wordsScalability 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?
    spoken · machine transcript hear it at 0:24:01 · all korrents from this recording

    ↗Designing Data-intensive Applications with Martin Kleppmannyoutube.com 2nd of 26 in this recording

    Interesting

  5. Our reading

    Scaling down is half of scalability: cost and capacity should track load in both directions, right down to a service that is nearly free to run.

    Their wordsgenerally, 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.
    spoken · machine transcript hear it at 0:25:37 · all korrents from this recording

    ↗Designing Data-intensive Applications with Martin Kleppmannyoutube.com 3rd of 26 in this recording

    Interesting

  7. Our reading

    Building databases on object stores is a genuine architectural break, because replication moves out of the database and into the storage layer.

    Their wordsAnd now suddenly people are building databases on top of object stores, for example. And now the replication happens at the object store level, no longer at the database level.
    spoken · machine transcript hear it at 0:29:38 · all korrents from this recording

    ↗Designing Data-intensive Applications with Martin Kleppmannyoutube.com 4th of 26 in this recording

    Interesting

  9. Our reading

    An engineer writing business logic loses nothing by not understanding the layer underneath, exactly as they lose nothing by not managing memory.

    Their wordsYou're building higher-level business logic, actually I think it's just fine for people not to care about memory management.
    spoken · machine transcript hear it at 0:31:55 · all korrents from this recording

    ↗Designing Data-intensive Applications with Martin Kleppmannyoutube.com 5th of 26 in this recording

    Interesting

  11. Our reading

    Higher-level abstractions do not abolish low-level knowledge; they concentrate it in the smaller group of people who build the abstractions.

    Their wordsBut, somebody still has to build those lower-level abstractions and from lower-level components. Somebody's got to implement the cloud services.
    spoken · machine transcript hear it at 0:32:17 · all korrents from this recording

    ↗Designing Data-intensive Applications with Martin Kleppmannyoutube.com 6th of 26 in this recording

    the cloud

    Interesting

  13. Our reading

    Knowing a little about how a storage engine works internally is a superpower for an application developer who will never build one.

    Their wordsAnd so those are those places where I feel like knowing a bit about the the internals is actually like a superpower.
    spoken · machine transcript hear it at 0:35:39 · all korrents from this recording

    ↗Designing Data-intensive Applications with Martin Kleppmannyoutube.com 7th of 26 in this recording

    Interesting

  15. Our reading

    Europe being locked out of US cloud services is still unlikely, but it is no longer unthinkable, and serious systems should be engineered against it.

    Their wordsSo, what if geopolitics was to go horribly wrong and tensions escalate and Europe find itself suddenly locked out of US cloud services? I hope that doesn't happen. I still think it's fairly unlikely, but it's no longer unthinkable.
    spoken · machine transcript hear it at 0:37:25 · all korrents from this recording

    ↗Designing Data-intensive Applications with Martin Kleppmannyoutube.com 8th of 26 in this recording

    Europe

    Interesting

  17. Our reading

    As AI writes more of the code, an engineer's job shifts away from expressing logic in a language and towards articulating high-level trade-offs.

    Their wordsMaybe as AI writes more and more code of our code, it's less about like the details of how you express logic in a particular programming language and much more about those kinds of high-level trade-offs.
    spoken · machine transcript hear it at 0:38:47 · all korrents from this recording

    ↗Designing Data-intensive Applications with Martin Kleppmannyoutube.com 9th of 26 in this recording

    Interesting

  19. Our reading

    Sharding across machines has faded as a concern because hardware got more powerful, not because the cloud made it easy.

    Their wordsBut, at least this sort of sharding across multiple machines is maybe become less of a pressing issue just because more and more workloads can just run on a single machine. Some people still have very large-scale workloads that do have to be sharded across multiple machines. So, it's not going away entirely.
    spoken · machine transcript hear it at 0:42:22 · all korrents from this recording

    ↗Designing Data-intensive Applications with Martin Kleppmannyoutube.com 10th of 26 in this recording

    the cloud

    Interesting

  21. Our reading

    Replication earns its place even in a small system, because what it buys is fault tolerance rather than scale.

    Their wordsAnd uh replication is still relevant even at smaller scales because that's for fault tolerance, that's not for scalability.
    spoken · machine transcript hear it at 0:42:37 · all korrents from this recording

    ↗Designing Data-intensive Applications with Martin Kleppmannyoutube.com 11th of 26 in this recording

    Interesting

  23. Our reading

    A distributed system must assume there is no upper bound whatsoever on how long a message can take to cross the network.

    Their wordswe just assume that there's no upper bound on how long it might take for a message to go over the network. So, you send a message, it might arrive within 100 microseconds, or it might take 10 years.
    spoken · machine transcript hear it at 0:43:07 · all korrents from this recording

    ↗Designing Data-intensive Applications with Martin Kleppmannyoutube.com 12th of 26 in this recording

    Interesting

  25. Our reading

    Clocks are right most of the time, and that is precisely why a distributed system may never rely on them.

    Their wordsit's very easy to assume that your clocks are correct and most of the times the clocks are pretty correct but we just can't rely on it because actually they're just not precise enough uh on the whole.
    spoken · machine transcript hear it at 0:44:34 · all korrents from this recording

    ↗Designing Data-intensive Applications with Martin Kleppmannyoutube.com 13th of 26 in this recording

    Interesting

  27. Our reading

    How much fault tolerance to buy is a business decision, not an engineering one; the engineer's job is to inform it and then step back.

    Their wordsAnd so, the goal of this chapter is really just to give people the information in order to make an educated decision. But I don't want to make that decision for people. That's for businesses themselves to decide.
    spoken · machine transcript hear it at 0:46:40 · all korrents from this recording

    ↗Designing Data-intensive Applications with Martin Kleppmannyoutube.com 14th of 26 in this recording

    Interesting

  29. Our reading

    MapReduce is dead: nobody uses it any more, and it survives in the literature only as a teaching device for its successors.

    Their wordsIn particular, for example, coverage of MapReduce was quite detailed in the first edition. But basically, MapReduce is dead. Nobody uses it anymore.
    spoken · machine transcript hear it at 0:47:11 · all korrents from this recording

    ↗Designing Data-intensive Applications with Martin Kleppmannyoutube.com 15th of 26 in this recording

    Interesting

  31. Our reading

    If you got into technology to change the world, then thinking about what your technology does to the world is part of the job, not an optional extra.

    Their wordspeople say that uh you get into tech in order to change the world. If you want to change the world, then thinking about the impact that your technologies have on the world is part of your job.
    spoken · machine transcript hear it at 0:50:32 · all korrents from this recording

    ↗Designing Data-intensive Applications with Martin Kleppmannyoutube.com 16th of 26 in this recording

    Interesting

  33. Our reading

    A test checks a handful of examples; a proof settles an infinite state space, which is why formal methods can say things testing never can.

    Their wordsBut a proof can reason about potentially infinite state spaces. So, it can tell you things about like every possible thing that could possibly happen in the entire universe.
    spoken · machine transcript hear it at 0:54:10 · all korrents from this recording

    ↗Designing Data-intensive Applications with Martin Kleppmannyoutube.com 17th of 26 in this recording

    Interesting

  35. Our reading

    Formal verification is about to become economical, because models are getting good enough at writing the proofs that humans no longer have to.

    Their wordsOne is that the LLMs are getting increasingly good at writing these proofs. And if we don't have to write the proof by hand as humans, it just becomes feasible to do them in situations where previously it would have not been economical.
    spoken · machine transcript hear it at 0:58:54 · all korrents from this recording

    ↗Designing Data-intensive Applications with Martin Kleppmannyoutube.com 18th of 26 in this recording

    LLMsformal proof

    Interesting

  37. Our reading

    AI-written code makes formal proof necessary, because human review of all that generated code becomes the bottleneck.

    Their wordsBut also LLMs increase the need for these formal proofs because, you know, we're live coding a bunch of stuff. If we have to manually review all of that code, then that will become the bottleneck.
    spoken · machine transcript hear it at 0:59:06 · all korrents from this recording

    ↗Designing Data-intensive Applications with Martin Kleppmannyoutube.com 19th of 26 in this recording

    LLMsformal proofcode generation

    Interesting

  39. Our reading

    Power over data belongs with end users rather than cloud operators, and software should be built to move it back to them.

    Their wordslocal-first software, which is this idea that we want to take away a bit of the power from cloud operators and give it back to end users. So, end users should be more in control of their own data and less dependent on cloud services for providing the applications and the data that that the users need.
    spoken · machine transcript hear it at 1:02:07 · all korrents from this recording

    ↗Designing Data-intensive Applications with Martin Kleppmannyoutube.com 20th of 26 in this recording

    Interesting

  41. Our reading

    The reason a software-as-a-service business can charge a subscription is that it holds a gun to the customer's head over their own data.

    Their wordssoftware as a service businesses, for example the whole reason why they can charge a subscription is because they are able to essentially hold a gun to the customer's head and say, "Pay us at your subscription, otherwise we will delete all your data."
    spoken · machine transcript hear it at 1:02:34 · all korrents from this recording

    ↗Designing Data-intensive Applications with Martin Kleppmannyoutube.com 21st of 26 in this recording

    SaaS

    Interesting

  43. Our reading

    Work that runs against companies' commercial incentives will only get done by people whose income does not depend on those incentives.

    Their wordsthere I feel like in academia, I have the freedom to work on things that go against this commercial incentive of companies and say like, "Actually, no, I'm going to do what I think is right for the users."
    spoken · machine transcript hear it at 1:03:11 · all korrents from this recording

    ↗Designing Data-intensive Applications with Martin Kleppmannyoutube.com 22nd of 26 in this recording

    Interesting

  45. Our reading

    Timestamps cannot order access-control decisions in a decentralised system, because the user whose access was revoked can simply forge them.

    Their wordsif a revoked user still wants to, say, vandalize a document, they can just backdate their edits, give it an earlier timestamp. So, relying on clocks is absolutely useless here because people can forge the timestamps from those clocks and thereby then potentially undermine the access control mechanism.
    spoken · machine transcript hear it at 1:07:44 · all korrents from this recording

    ↗Designing Data-intensive Applications with Martin Kleppmannyoutube.com 23rd of 26 in this recording

    Interesting

  47. Our reading

    The essay a student hands in is not the point of education; the thought process that produced it is the entire desired outcome.

    Their wordsWe don't ask the students to write essays because we love reading their amazing essays. We ask them to write essays because they we want them to go through a thought process, which helps them learn something.
    spoken · machine transcript hear it at 1:15:49 · all korrents from this recording

    ↗Designing Data-intensive Applications with Martin Kleppmannyoutube.com 24th of 26 in this recording

    Interesting

  49. Our reading

    Writing is how the thinking gets done, so a writer who hands the words to a machine has given away the part that mattered.

    Their wordsIt's more that for myself, the process of writing is the way how I figure things out. And figuring things out is really my goal here. So, I'm I'm trying to figure it out in my own heads, and for that I just have to write it myself.
    spoken · machine transcript hear it at 1:21:51 · all korrents from this recording

    ↗Designing Data-intensive Applications with Martin Kleppmannyoutube.com 25th of 26 in this recording

    Interesting

  51. Our reading

    People in industry routinely short-circuit their reasoning, adopting what they heard in a conference talk instead of thinking it through from first principles.

    Their wordsOften people in industry I feel like sort of have short circuit reasoning. Like don't maybe don't quite reason something through from first principles but just like oh I heard this from a conference talk I'm just going to go with that
    spoken · machine transcript hear it at 1:23:42 · all korrents from this recording

    ↗Designing Data-intensive Applications with Martin Kleppmannyoutube.com 26th of 26 in this recording

    Interesting