# Revisiting reliability assumptions can produce new system designs

Markdown copy of https://realalpha.app/s/revisiting-reliability-assumptions-can-produce-new-system/ on Real Alpha, the best minutes from long interviews with the people building AI. Cite and link the page, not this copy.

- Speaker: [Jeff Dean](https://realalpha.app/builders/jeff-dean/) · Jeff Dean is Chief Scientist at Google. · Co-founded AI startup Discovery Loop; previously Google chief scientist and co-creator of MapReduce, Bigtable.
- Host: [Diana Hu](https://realalpha.app/people/diana-hu/) · Managing partner, Y Combinator · CTO of Escher Reality; after Niantic bought it, ran AR for Pokémon GO.
- Show: Lightcone
- Episode: [Jeff Dean: The 1% Rule for Building in AI](https://realalpha.app/v/CxXgV54KzpQ/), Jul 30, 2026
- Moment: 36:30 to 42:12 of the episode (6 min), playing on https://realalpha.app/s/revisiting-reliability-assumptions-can-produce-new-system/; the episode from there: https://realalpha.app/v/CxXgV54KzpQ/?t=2190

## Quote

> “what would happen if you tried to build a system out of transistors that might have **20 errors per day** rather than one every million years”
> — [Jeff Dean](https://realalpha.app/builders/jeff-dean/) at [38:25](https://realalpha.app/v/CxXgV54KzpQ/?t=2305) · Lightcone

## Takeaways

1. Consider designs that tolerate frequent component errors.
2. MapReduce put checkpointing and reliability below the computation.
3. Question inherited assumptions to find useful new abstractions.

## About this segment

Jeff Dean imagines building with error-prone transistors, then recounts how MapReduce separated computation from reliability code. Both examples show how questioning a constraint can lead to a new design.

From “Jeff Dean: The 1% Rule for Building in AI”, Jul 30, 2026. [Watch the full episode](https://realalpha.app/v/CxXgV54KzpQ/)

## Transcript

Transcribed by machine (Whisper) from the episode’s audio, so a word may be off here and there.

[36:35](https://realalpha.app/v/CxXgV54KzpQ/?t=2195) I think a third way we were talking earlier was doing very crazy thought experiments. Oh, yeah. That's another good way. I mean, I think sometimes it's good to not take as a given things that most people seem to take as a given. So I was doing a crazy thought experiment with some colleagues the other day about, you know, for 60 years, the whole silicon chip design industry, design and fabrication industry have, you know, done tremendous work to make smaller and smaller scale transistors that are very low error rate.

[37:21](https://realalpha.app/v/CxXgV54KzpQ/?t=2241) right like because what what the assumption that we want is that every chip we manufacture of the same design should be identical to every other chip you don't want any bits to flip everything no bits should flip there's all kinds of things you there's all kinds of error margins built into you know memories have ecc memory these days um you know at the at the macro scale we don't make that assumption when we're building large-scale distributed systems right we we build reliable, large-scale distributed file systems out of unreliable parts, right? Like individual disks can fail, but your data should be safe. And so we have mechanisms at a higher level to enable us to have, you know, three copies of the data on three different machines and three different racks, so that if any rack switch or individual machine or disk fails,

[38:11](https://realalpha.app/v/CxXgV54KzpQ/?t=2291) you still have your data. We have Reed Solomon encoding techniques. But we don't seem to do this at a really extreme level in the sort of transistor scale of the technology we're working on. So basically an interesting thought experiment is what would happen if you tried to build a system out of transistors that might have 20 errors per day rather than one every million years, right? That would be a very different design point and might enable you to do really interesting things and the fabrication side of things.

[38:48](https://realalpha.app/v/CxXgV54KzpQ/?t=2328) You have very different kind of design methodologies because if you want to get a signal from here to there and you have these super unreliable transistors, you might have very different ways of signaling. You might send it along multiple redundant paths in order to make sure that it gets along one of them. And I think that would be a pretty interesting set of thought experiments. I'm not saying we should go do this, but that's the kind of thing where you do want to occasionally question assumptions. Now, oftentimes, these thought experiments don't work out because there are very good reasons that, you know, for the last 50 years, we've done this thing this way and not that way. But it's good to kind of revisit those every so often.

[39:32](https://realalpha.app/v/CxXgV54KzpQ/?t=2372) That is so wild. I mean, it's starting to rhyme a lot with neuromorphic computing or the human brain and how nature works. I mean, exactly. Like, signals in our brain are not especially reliable from getting one place to another and so i think in brains when there are really important things you need to get from one place to another there are multiple pathways that that enable you to sort of do that.

[39:56](https://realalpha.app/v/CxXgV54KzpQ/?t=2396) What is, I mean, you have such an impressive career. What is one of these crazy assumptions that you threw out of the window that actually built a consequential system in the past? Yeah, I mean, I guess, uh, that worked out actually. Yeah. I mean, I think, uh, well, TPUs is a good example, like being able to specialize hardware for a very niche problem domain before that problem domain seemed as important as it is today, uh, is one thought experiment.

[40:26](https://realalpha.app/v/CxXgV54KzpQ/?t=2426) Um, you know, I think the, uh, And the origin of MapReduce is another good example. It's a legendary. So we had worked, Sanjay and myself and a number of other colleagues had worked on various iterations of the crawling and indexing system at Google. And, you know, we'd sort of written lots of hand-parallelized code with lots of checkpointing to make sure it would be robust and reliable if it was running on 100 computers or 1,000 computers and some of those died.

[40:59](https://realalpha.app/v/CxXgV54KzpQ/?t=2459) But that code tended to be intermixed with the actually relatively simple thing you often were trying to do. Like, I just want to look at all the contents of all the webpages and then compute on the side mapping from URL to what language is this page in, it's the text in this page. And it would get obscured by all this kind of other code for parallelization and reliability. And so we sort of remembered our training in functional languages and realized we could squint at those problems and develop this map-produce-abstraction that you could have above this implementation.

[41:38](https://realalpha.app/v/CxXgV54KzpQ/?t=2498) And then below the implementation, you could put all the checkpointing and reliability mechanisms into that lower-level library that everything could then build on. And so that became a hugely successful way of dealing with very large-scale computations at Google in a robust and reliable way from that thought experiment of like, well, if we squint at it, could we find lots of problems that fit into this abstraction?

[42:03](https://realalpha.app/v/CxXgV54KzpQ/?t=2523) That's impressive. So this thought experiment led you to create MapReduce. Awesome.