List of Figures

Chapter 1. Brave new world

Figure 1.1. Iteration 0: Messages and services that support posting and listing entries

Figure 1.2. Iteration 1: Adding messages and services that support searching entries

Figure 1.3. Iteration 2: An entry store cache implemented by message capture

Figure 1.4. Iteration 3: Adding social timelines

Figure 1.5. Iteration 3: Scaling by sharding at the message level

Figure 1.6. The underlying infrastructure that moves messages shouldn’t be known to microservices.

Figure 1.7. Introducing support for new user profiles

Figure 1.8. Additivity allows a system to change in discrete, observable steps.

Chapter 2. Services

Figure 2.1. A possible component architecture for the newspaper system

Figure 2.2. Building the article page

Figure 2.3. Building the full article page

Figure 2.4. Letting other services know that an article has been read

Figure 2.5. The scatter/gather pattern

Figure 2.6. The full newspaper system

Figure 2.7. Service and network element deployment characteristics

Figure 2.8. Message interactions

Figure 2.9. Extending the article service without modification

Figure 2.10. Introduction of new functionality into the live system

Chapter 3. Messages

Figure 3.1. Conceptual levels of system design

Figure 3.2. Request/response pattern: the calculation of sales tax, where microservice A is the shopping-cart service, microservice B is the sales-tax service, and the message is calculate-sales-tax. The shopping-cart service expects an immediate answer so it can update the cart total.

Figure 3.3. Sidewinder pattern: in the e-commerce system, the shopping-cart service may send a checkout message to the delivery service. A recommendation service can observe the checkout messages to understand the purchasing behavior of customers and generate recommendations for other products they might be interested in. But the existence of the recommendation service isn’t known to the shopping-cart and delivery services, which believe they’re participating in a simple request/response interaction.

Figure 3.4. Winner-take-all pattern: in the e-commerce system, you can configure the delivery service to work in this mode. For redundancy and fault tolerance, you run multiple instances of the delivery service. It’s important that the physical goods are delivered only once, so only one instance of the delivery service should act on any given checkout message. The message interaction is asynchronous in this configuration, because shopping-cart doesn’t expect a response (ensuring delivery isn’t its responsibility!). You could use a message bus that provides work queues to implement this mode of interaction.

Figure 3.5. Fire-and-forget pattern: the general form of this interaction involves a set of different microservices observing an emitted message. The shopping-cart service emits a checkout message, and various other services react to it: delivery, checkout-email, and perhaps audit. This is a common pattern.

Figure 3.6. Request/react pattern

Figure 3.7. Batch progress reporter

Figure 3.8. Orchestra

Figure 3.9. Scatter/gather

Figure 3.10. Multiversion deployment

Figure 3.11. Multi-implementation deployment

Figure 3.12. Chain

Figure 3.13. Tree

Chapter 4. Data

Figure 4.1. Using different databases for different microservices

Figure 4.2. Local user profile data stored only on shard instances

Figure 4.3. Interaction between the article-page and article services

Figure 4.4. Composing the article-page and article services together

Figure 4.5. CRUD message flow compared to CQRS message flow

Figure 4.6. Direct synchronous interaction with the search-engine service

Figure 4.7. Reactive asynchronous interaction with the search-engine service

Figure 4.8. Eventually consistent data interactions

Figure 4.9. Immediately consistent data interactions

Figure 4.10. Deployment sequence to replace a shard

Figure 4.11. Deployment sequence to split a shard

Figure 4.12. Operations performed to allow a user to read an article

Figure 4.13. Trade-offs when choosing conflict resolution strategies

Chapter 5. Deployment

Figure 5.1. High-level components of a nuclear reactor

Figure 5.2. A small subset of interactions between high and low levels in the reactor

Figure 5.3. A single-component system, where P0 is the failure rate of component C0

Figure 5.4. A two-component system, where Pi is the failure rate of component Ci

Figure 5.5. Probability of system failure against the number of components, where all components are 99% reliable

Figure 5.6. A nonlinear four-component system

Figure 5.7. A skewed estimator of failure probability

Figure 5.8. Estimated reliability of the system when four components change simultaneously

Figure 5.9. Microservice diagram key

Figure 5.10. Rollback pattern sequence

Figure 5.11. Homeostasis pattern sequence

Figure 5.12. History pattern sequence

Figure 5.13. Canary pattern sequence

Figure 5.14. Progressive Canary pattern sequence

Figure 5.15. Bake pattern sequence

Figure 5.16. Merge pattern sequence

Figure 5.17. Split pattern sequence

Figure 5.18. Apoptosis pattern sequence

Figure 5.19. Mitosis pattern sequence

Figure 5.20. Kill Switch pattern sequence

Figure 5.21. Version Update pattern sequence

Chapter 6. Measurement

Figure 6.1. Classical response-time charts

Figure 6.2. Histogram chart showing response times

Figure 6.3. Histogram chart showing response times, with caching causing two peaks

Figure 6.4. Histogram chart (no cache) showing response times, with 90th percentile

Figure 6.5. Histogram chart (with cache) showing response times, with 90th percentile

Figure 6.6. Time series chart of average and 90th percentile response times

Figure 6.7. Scatterplot of weight (in kilograms) versus height (in centimeters)

Figure 6.8. Current-behavior scatterplot of microservice response times

Figure 6.9. Synchronous message outbound send and response counts

Figure 6.10. Outbound response failure counts over time

Figure 6.11. Current response-time behavior by message family

Figure 6.12. Different message transports have different delivery speeds.

Figure 6.13. Current behavior of service instances of the same type

Figure 6.14. Categorical scatterplot of service-instance response times

Figure 6.15. Ratio of message-flow rates

Figure 6.16. Messages caused by posting an entry

Figure 6.17. Actor/service interaction

Figure 6.18. Publish/subscribe service interaction

Figure 6.19. Service/chain interaction

Figure 6.20. Service/tree interaction

Figure 6.21. Distributed trace of an entry post over microservices

Chapter 7. Migration

Figure 7.1. The basic legacy e-commerce architecture

Figure 7.2. The evolving product microservice family

Figure 7.3. Number of product types that each microservice handles

Chapter 8. People

Figure 8.1. Value versus complexity matrix

Chapter 9. Case study: Nodezoo.com

Figure 9.1. The role:search, cmd:search interaction

Figure 9.2. The role:search, cmd:insert interaction

Figure 9.3. The role:info,cmd:get interaction

Figure 9.4. The role:info,need/collect:part interactions

Figure 9.5. The role:npm,cmd:* interactions

Figure 9.6. The role:info, event:change interaction

Figure 9.7. The system after iteration 1

Figure 9.8. Deployment-risk score

Figure 9.9. Message-flow rates and invariants

Figure 9.10. Current behavior for message response times

Figure 9.11. Dynamic service relationships

Figure 9.12. Trace of the search message flow over services

Figure 9.13. Searching the service logs