Errata for Designing Data-Intensive Applications

"[...] code generation is an unnecessarily obstacle to getting to the data." -> "[...] code generation is an unnecessary obstacle to getting to the data."

Note from the Author or Editor:
I have made this change in Atlas

Reference [11] Andrew Wang: “Windows Azure Storage,” umbrant.com, February 4, 2016. should link to https://www.umbrant.com/2016/02/04/windows-azure-storage/

Note from the Author or Editor:
URL of the blog post has changed. We're updating it to https://www.umbrant.com/2016/02/04/windows-azure-storage/

Reference [18] Jay Kreps, Neha Narkhede, and Jun Rao: “Kafka: A Distributed Messaging System for Log Processing,” is no longer available at that URL. Suggested alternative: https://www.microsoft.com/en-us/research/wp-content/uploads/2017/09/Kafka.pdf

Note from the Author or Editor:
I have updated the URL in Atlas and on https://github.com/ept/ddia-references

New types of database [system] (“NoSQL”) have been getting lots of attention, but message queues, caches, search indexes, frameworks s/b systems

Note from the Author or Editor:
Fixed in next Early Release update.

In this Chapter 1, we will start by exploring the fundamentals of what we are trying to achieve: reliabile, scalabile and maintainable data systems reliabile -> reliable scalabile -> scalable

Note from the Author or Editor:
Fixed in next Early Release update.

compilation is written with a typo as compliation. Code generation is often frowned upon in these languages, since they otherwise avoid an explicit compliation step.

Note from the Author or Editor:
Fixed in next early release update.

following choice of words feels awkward (unpack): In the rest of this chapter we will unpack some of the most common ways how data flows between processes: It would seem that reveal, show,or describe would be a more common fit than unpack.

Note from the Author or Editor:
Fixed in next early release update.

In the sub-section "The truth is defined by the majority" of section "Knowledge, Truth and Lies", a typo in the paragraph below figure 8-5: However, the storage server rembers that it has already processed a write with a higher token number (34), and so it rejects the request with token 33. "rembers " -> "remembers"?

Note from the Author or Editor:
Fixed in next early release update.

"As it takes just one slow call to make the entire end-user request slow, rare slow calls to the backend become much more frequent at the end-user request level" should probably be reworded. 1. Saying "the backend" can be misleading, and is technically inaccurate. It's *multiple* backends. It's only with multiple backends that this increase in frequency of slow end-user requests makes sense. 2. It would be more technically accurate and better to say that it is the *collective frequency* of any slow call to any backend that increases. The slow calls themselves do not exactly increase in frequency.

"data model" should be pluralized in 'There are many different kinds of data model' (should be 'There are many different kinds of data models')

... where the the database ... better written with just one 'the'

Note from the Author or Editor:
Fixed in next Early Release update.

The following sentence has a typo: "In a graph database, there are is no such restriction: any vertex can have an edge to any other vertex." It should be: "In a graph database, there is no such restriction: any vertex can have an edge to any other vertex."

TLDR for the below comments: The second and third paragraphs downplay the differences with Bitcask, which was pretty confusing to me at first. Unless I'm mistaken, this sentence ("We also require that each key only appears once within each merged segment file (the compaction process already ensures that).") would be more accurately/helpfully written ("We also require that each key only appears once within each segment file. Incoming keys are consolidated by a tree structure that we will discuss shortly.") This resolves my first confusion, because I thought you were implying that segment files could have multiple entries per key until they were merged. Also, the sentence "At first glance, that requirement seems to break our ability to use sequential writes, but we’ll get to that in a moment" might be more helpfully written "This means that we cannot append new keys directly to the segments (as in Bitcask) because we can only have one entry per key/segment. However, creation of new segment files is still performed using sequential writes, as we will show in a moment." This resolves my second confusion, because I thought you were implying that you would show how all new data could still be written directly to the segments.

Note from the Author or Editor:
Thanks for the suggested wording improvements. In the next update of the book I will tweak the wording to avoid this confusion.

"increasinly" should be "increasingly"

Note from the Author or Editor:
Fixed in next Early Release update.

Is it right? "From time to time to time", I think it is mis typo of "From time to time"

Note from the Author or Editor:
Remove spurious "to time".

There are two common ways how data is distributed across multiple nodes: /del "how"

Note from the Author or Editor:
Fixed in next Early Release update.

After figure 6-2, the text states that Volume 12 of the pictured encyclopedia (Trudeau - Zywiec) contains "words starting with T, U, V, X, Y, and Z." However, assuming that the encyclopedia uses the English alphabet, it would also contain words starting with W.

"each partitions maintains..." should be "each partition maintains..."

Note from the Author or Editor:
Fixed in next Early Release update.

Under the billeted list outlining developments that caused a rethink: RAM became cheap enough that for many use cases is now feasible to keep.... "is now" should read "it is" or "it's".

"packed-switched" in "Ethernet and IP are packed-switched protocols" should be "packet-switched"

Note from the Author or Editor:
Will be fixed in QC1

"These jumps, as well as the fact that they often ignore leap seconds, make time-of-day clocks unsuitable for measuring elapsed time" Based on the reference you linked, it seems the CloudFlare problem was actually that the clock used by its code DID take leap seconds into account, but the application code ignored the fact that this could happen. So perhaps a better phrasing would be: "These jumps, as well as similar jumps caused by leap seconds, make time-of-day clocks unsuitable for measuring elapsed time" In other words the problem isn't that time-of-day clocks ignore leap seconds, it's the reverse, that they are affected by them. But then the application code ignores the fact that this can happen.

Note from the Author or Editor:
I agree with the suggested wording change, and have updated the text in Atlas.

Minor problems with plurals: ...even if a nodes believes that it is... [change 'nodes' to 'node'] ... mean the majority of nodes agrees! ... [change 'agrees' to 'agree']

Note from the Author or Editor:
Fixed in next early release update.

The wording feels a bit awkward in - 'The only way how information can flow...' Perhaps drop 'how'? 'The only way information can flow ...'

Note from the Author or Editor:
Fixed in next early release update.

"...are easier use correctly" should be "...are easier to use correctly"

Note from the Author or Editor:
Fixed in copyedit

Unnecessary repeat of word 'first' in same sentence, keeping the first one and suppressing the second one would do: But first we first need to explore the range of guarantees...

TYPO: "commiting the write" should be "committing the write" Redundancy: "The blocking of readers and writers is implemented by a having a lock on each object in the database." Should be: "implemented by having a lock on "

Note from the Author or Editor:
Fixed in Atlas.

Hard to tell because I use kindle, thus I don't see pages but locations in location 6130 and the first paragraph you see a repeated "to" "When a transaction wants to to commit."

Note from the Author or Editor:
Fixed in next Early Release update.