Description
Book SynopsisIn the simplest terms, event-driven architectures are like onions; they are manageable as a single layer (like a monolith) but when you get into them, they begin to cascade apart and you quickly realize that there are many complex layers (distributed microservices architecture). And that's when the tears begin. This prescriptive guide takes you through the steps of moving a platform with millions of users from a monolith to a microservices event-driven architecture. You will learn about the challenges and complexities that arise in high-throughput environments that often contain upwards of hundreds of microservices. This book is designed to be your single best resource for learning how to apply event-driven architectures in real-world scenarios and offers hundredsof patterns to overcome the common and not so common challenges. While event-driven architectures have been the standard for decoupled, pluggable, evolutionary architectures for years, they have onlyrecently been adopted b
Table of ContentsChapter 1. Embracing event-driven architectures
1.1. The truth about monoliths
1.1.1. Anatomy of a typical monolith
1.1.2. It's not all bad
1.1.3. When monoliths become the business constrictor knot
1.1.4. Using event-driven architectures to move away from a monolith
1.2. What are microservices and how do they relate to event-driven
1.3. SOA, microservice, and event-driven architectures
1.4. The promise of event-driven microservices
1.5. When should you use event-driven microservices?
1.6. Overview of the challenges in event-driven architectures
1.7. Summary
Chapter 2. Moving from a monolith to an event-driven architecture
2.1. Is migrating to an event-driven architecture your best option?
2.2. How to decide where to start
2.3. Using an event-driven approach to migrate data
2.4. Using change data capture (CDC)
2.4.1. Event-driven and change data capture (CDC), a real-world example
2.5. Event-driven as a source of truth for both systems
2.6. Managing dependencies between the two systems
2.6.1. Dependency from new event-driven services to the monolith
2.6.2. Dependency from the monolith to new event-driven services
2.7. Gradually moving traffic
2.8. Two-way synchronization and living with two sources of truth
2.9. Summary
Chapter 3. Defining an event-driven microservice and its boundaries
3.1. Building event-driven microservices
3.1.1. Durable vs. ephemeral message brokers and GDPR
3.1.2. Message types
3.1.3. When to use documents over events
3.1.4. Common event-driven messaging patterns
3.1.5. Event-driven service topologies
3.1.6. Common event-driven pitfalls and anti-patterns
3.2. Organizing event-driven microservice boundaries
3.3. Brief and practical introduction to domain-driven design and bounded contexts
3.4. The impact of aggregate size and common pitfalls
3.5. Request-driven vs. event-driven services
3.6. Adding functionality to an existing microservice vs. creating a new one
3.7. Summary
Chapter 4. Event-driven structural patterns and high-level processes
4.1. The challenges of transactional consistency in distributed systems
4.1.1. Why abandon a monolithic database in the first place?
4.1.2. The limitations of distributed transactions
4.1.3. Managing multi-step processes with Sagas
4.2. Event-driven orchestration pattern
4.3. Event-driven choreography pattern
4.4. Orchestration, choreography, or both?
4.5. Data retrieval in event-driven architectures and associated patterns
4.5.1. CQS, CQRS and when to use them
4.5.2. The different flavors of CQRS
4.5.3. When and how to use event sourcing
4.5.4. Using command sourcing and its applicability
4.6. Building multiple read models
4.7. The pitfall of microservice spaghetti architectures and how to avoid it
4.8. Summary
Chapter 5. How to manage eventual consistency
5.1. The impacts of eventual consistency and the need for alignment with the business
5.2. Using event schema to leverage eventual consistency
5.3. Applying domain boundaries to leverage eventual consistency
5.4. Event versioning to manage delays
5.5. Saving state to avoid eventual consistency
5.6. End-to-end argument: a real-world use case
5.7. For most use cases, it's not eventual if nobody notices
5.7.1. Autoscaling use case with Prometheus and Kafka
5.8. Tradeoffs of each solution
5.9. Summary
Chapter 6. Dealing with event-driven concurrency and out of order messages
6.1. Why is concurrency different in a monolith from an event-driven architecture?
6.2. Pessimistic vs. optimistic concurrency, when and when not to use
6.2.1. Pessimistic vs. optimistic approaches
6.2.2. Solving concurrency by implementation and by architecture
6.3. Using optimistic concurrency
6.4. Using pessimistic concurrency
6.4.1. Distributed locks
6.4.2. Database transactions
6.5. Dealing with out-of-order events
6.5.1. How can events lose their order?
6.5.2. Solving out of order events with versioning
6.6. Using end-to-end message partitioning to handle concurrency and guarantee message ordering
6.6.1. The relevance of message routing and partitioning
6.6.2. Real-world example of message routing using Kafka
6.6.3. Using end-to-end partitioning
6.6.4. Limitations of end-to-end partitioning
6.7. Summary
Chapter 7. Achieving resilience and event processing reliability in event-driven microservices
7.1. Common failures in microservice architectures and how they relate to event-driven architectures
7.1.1. Cascading failures and event-driven services
7.1.2. Load balancing and rate limiters in event-driven services
7.2. Understanding message delivery semantics
7.3. Avoiding inconsistencies when saving state and publishing events
7.3.1. Event stream as the only source of truth
7.3.2. Outbox pattern
7.3.3. Transactions and compensating actions
7.4. Applying ACID 2.0 as a resilience strategy
7.5. Avoiding message leak
7.6. Applying common resilience patterns
7.6.1. Retries
7.6.2. Circuit breakers
7.7. Recovering data and repairing state
7.8. Bulkhead pattern
7.9. Summary
Chapter 8. Choosing the correct event schema design
8.1. Event storming
8.2. Event headers and envelopes
8.2.1. Headers vs envelopes
8.2.2. Relevant event contextual information
8.3. Town crier events
8.4. Bee events
8.5. The event schema goldilocks principle
8.6. Denormalized event schema
8.7. Schema evolution
8.7.1. Event stream versioning
8.7.2. Using a downscaler/upscaler
8.8. Summary
Chapter 9. How to leverage the user interface
9.1. Using an aggregating layer
9.2. Backends for frontends
9.3. UI Decomposition
9.3.1. Application decomposition
9.3.2. Page decomposition
9.3.3. Section decomposition
9.4. The limitations of API composition
9.5. Task-based UIs
9.6. Event-driven APIs
9.7. Summary
Chapter 10. Overcoming the challenges in quality assurance
10.1. The only happens in production syndrome
10.2. Component tests vs integration tests
10.3. The correct mix of component validation and production validations
10.4. Monitoring and alarmistic from the ground up
10.5. Summary
Chapter 11. Organizational cost of event-driven microservices
11.1. The epic journey to be onboarded
11.2. When implementation overhead impacts time to market
11.3. Dependencies management
11.4. Summary
