The errata list is a list of errors and their corrections that were found after the product was released. If the error was corrected in a later version or reprint the date of the correction will be displayed in the column titled "Date Corrected".
The following errata were submitted by our customers and approved as valid errors by the author or editor.
| Version |
Location |
Description |
Submitted By |
Date submitted |
Date corrected |
|
Page n/a
text |
Current Copy
This could be something as simple as asking consumers to put their identifer in the user-agent header when making HTTP requests, or you could require that all calls go via some sort of API gateway where clients need keys to identify themselves.
Suggested
"their identifer in" should be "their identifier in"
Note from the Author or Editor:
Chapter 5, in the section "tracking usage".
identifer -> identifier |
Anonymous |
Dec 06, 2021 |
Jul 08, 2022 |
|
Page n/a
text |
Current Copy
8 There I explore its use in helping migrate functionality from a monolithic system to a microservice architecture, where we want to ensure that our new microservice behaves in the same way as the equivilent monolith functionality.
Suggested
"the equivilent monolith" should be "the equivalent monolith"
Note from the Author or Editor:
Chapter 8, last paragraph of the "parallel run" section.
equivilent -> equivalent |
Anonymous |
Dec 06, 2021 |
Jul 08, 2022 |
|
Page n/a
text |
Current Copy
End-to-end tests absolutely can help catch these semantic breakagaes, but they do so at a great cost.
Suggested
"semantic breakagaes, but" should be "semantic breakages, but"
Note from the Author or Editor:
Confirmed! Fourth paragraph of "Should You Avoid End-to-End Tests?" section.
breakagaes -> breakages |
Anonymous |
Dec 06, 2021 |
Jul 08, 2022 |
|
Page n/a
text |
Current Copy
Sometimes expending the same effort on getting better at fixing probems when they occur can be significantly more beneficial than adding more automated functional tests.
Suggested
"probems when they" should be "problems when they"
Note from the Author or Editor:
This looks like a typo got missed. I don't have a page number for this, but it's the first sentence of the the second paragraph of "Mean Time to Repair over Mean Time Between Failures?" section. probems -> problems |
Anonymous |
Dec 06, 2021 |
Jul 08, 2022 |
|
Page n/a
text |
Current Copy
Ideally, our teams are aligned around end-to-end slices of functionality, allowing each team to deliver new features to its customers while reducing the amount of coordinaton needed.
Suggested
"amount of coordinaton" should be "amount of coordination"
Note from the Author or Editor:
Confirmed!
In chapter 14, first paragraph of "Towards Stream-Aligned Teams".
"amount of coordinaton" should be "amount of coordination"
|
Anonymous |
Dec 06, 2021 |
Jul 08, 2022 |
|
Page n/a
text |
Current Copy
Function as a Service (FaaS) A type of serverless platform that invokes arbitary code based on certain types of triggers— for example, launching code in reaction to an HTTP call, or a message being received.
Suggested
"invokes arbitary code" should be "invokes arbitrary code"
Note from the Author or Editor:
This is in the glossary, and I think this is just a straight up typo - "arbitary" -> "arbitrary". Page 570 in the dead tree version. |
Anonymous |
Dec 06, 2021 |
Jul 08, 2022 |
| Printed, |
Page 40
2 para, after figure 2-6 |
The sentence "While this will help protect the Warehouse microservice from some changes to the shipping..." should instead read:
While this will help protect the Order Processor (instead of Warehouse) microservice from some changes to the shipping..."
|
Sam Newman
|
Apr 11, 2023 |
|
|
Page 48
Fig 2-9 |
Finite state machine diagram lacks Completed state. Additionally Cancelled state is there despite not being introduced in text.
Note from the Author or Editor:
I'm not inclined to add a "completed" state here, as I think it is clear that both cancelled and shipped perform that role. A bigger problem is that the text which references this diagram is wrong.
In the second paragraph on page 48, the last sentence reads "...to move a status straight from PLACED to COMPLETED" is wrong, as the diagram has SHIPPED, not COMPLETED. So this sentence should read "...to move a status straight from PLACED to SHIPPED" instead. |
Anonymous |
Oct 17, 2021 |
Jul 08, 2022 |
|
Page 57
Last paragraph |
Last paragraph mentions “In Figure 2-14 we saw that a customer exists in both locations”, where locations refer to the warehouse and the finance bounded contexts. However such figure does not contain any costumer. What’s shared across bounded contexts in the exemple given is the stock item model.
Note from the Author or Editor:
Totally correct - the references to "customer: in the "Shared Models" section need to be changed to "Stock Item". This isn't a quick fix though, as the description here discusses concepts related to the now non-existent customer (e.g. references to the orders placed by that person). So the two paragraphs here need to be reworked.
Suggested changes (bottom of page 57, top of page 58):
We can also have concepts that appear in more than one bounded context. In <<a30-context-diagram>> we saw that a +Stock Item+ exists in both locations. What does this mean? Is the +Stock Item+ copied? The way to think about this is that conceptually, both finance and the warehouse need to know something about the same Stock Item. Finance needs to know about the value of our stock to be able to determine our company valuation, whereas the warehouse needs to know about the stock item to know where the physical thing can be found in the warehouse for the purpose of packaging orders to be sent out.
When you have a situation like this, a shared model like stock item can have different meanings in the different bounded contexts and therefore might be called different things. We might be happy to keep the name "stock item" in warehouse, but in finance we might refer to it more generically as an "asset," as that is the role they play in that context. We store information about the stock item in both locations, but the information is different. Finance stores information about the stock item's value; the warehouse stores information related in what location(s) the item is to be found. We still may need to link both local concepts to a global concept of the item, and we may want to look up common, shared information about that stock item like their name or supplier—we could use a technique like that shown in <<customer_references>> to manage these lookups. |
Cassio Mazzochi Molin |
May 30, 2022 |
Jul 08, 2022 |
|
Page 65
1st paragraph |
Almost at the end of the paragraph ... Rust, which enables you to eke out additional performance improvements,...
Note from the Author or Editor:
I'm not 100% sure of the reporter's issue here, but I think that properly we should change "in a runtime like Rust," to "in a language like Rust" |
Adrian Gonzalez |
Jan 23, 2022 |
Jul 08, 2022 |
|
Page 98
Figure 4-4 |
Figure 4-4 shows Customer microservice calling Order Processor microservice to check for fraud. According to the Figure 4-3, on which Figure 4-4 is based, it was the Payment microservice that was making a call to check for fraud before the Fraud Detection was moved out of the critical path. The text does not clearly state the reason for the change leaving the reader wondering whether it should be rather the Payment microservice making the check for fraud call to Customer microservice?
Note from the Author or Editor:
The text on the arrow in figure 4-4 is wrong. The arrow from Customer to Order Processor should say "Flag customer as fradulent". |
Anonymous |
Jun 06, 2022 |
Jul 08, 2022 |
|
Page 99
First paragraph, first sentence |
"are decoupled temporarily" should be "are decoupled temporally"
I think it's describing that the two microservices don't have to be available at the same time i.e. they're decoupled in time (temporally) and not that they're only decoupled for a short period of time (temporarily)
Note from the Author or Editor:
The suggested change is appropriate - Temporally NOT temporarily |
Anonymous |
Dec 20, 2021 |
Jul 08, 2022 |
|
Page 110
6th line of 2nd paragraph |
„into Notifications and Payment” should be „into Notifications and Inventory”
Note from the Author or Editor:
Good spot! Needs to get fixed. |
Anonymous |
Oct 24, 2021 |
Jul 08, 2022 |
| Printed |
Page 110
Second paragraph |
The text "Here, we are pushing responsibility from Warehouse into Notifications and Payment" should be changed to "Here, we are pushing responsibility from Warehouse into Notifications and Invetory", as this matches the referenced figure on the previous page (4-11).
|
Sam Newman
|
Jul 01, 2022 |
Jul 08, 2022 |
|
Page 227
Figure 8-9 |
Figure 8-9 has 2 arrows in the bottom. I think the Faster Feedback should point to the left.
Note from the Author or Editor:
Yep, this needs a fix - on the bottom of Figure 8-9, there are two arrows, one above the other. The top of the arrows with the "faster feedback" label needs to point in the other direction. |
Spyridon Doulgeridis |
Jul 14, 2022 |
|
|
Page 311
Definition of observability |
Jjust to point a small error in p.311. In the definition of observabiltiy it is "outputs" not "inputs".
Note from the Author or Editor:
Correct! This needs to be fixed. Top of page 311 - "...based on external inputs" -> "...based on external outputs". |
Anonymous |
Jan 06, 2022 |
Jul 08, 2022 |