Are your microservices just a distributed monolith? Learn how to build truly resilient systems by rethinking service boundaries.
#1about 3 minutes
The pitfalls of synchronous microservice communication
Synchronous calls between services create tight coupling and lead to cascading failures when downstream systems experience latency.
#2about 4 minutes
Decoupling services with asynchronous message queues
Using message queues like RabbitMQ isolates high-latency services and improves system resilience by changing from immediate creation to eventual acceptance.
#3about 4 minutes
Avoiding the entity service anti-pattern in architecture
Slicing microservices based on data entities like 'user' or 'account' creates dependencies across teams and slows down feature development.
#4about 7 minutes
Using push-based streams for data synchronization
Reactive systems push data changes through event streams, allowing services to build local read models (projections) and achieve runtime autonomy.
#5about 7 minutes
Navigating the challenges of eventual consistency
Eventual consistency involves three main challenges—divergence, variance, and latency—which can be managed with ordering, deduplication, and optimistic UIs.
#6about 5 minutes
The key benefits of building reactive systems
Reactive architectures improve resilience and enable horizontal scaling by creating autonomous services that can build real-time, push-based user interfaces.
#7about 2 minutes
Decomposing monoliths with change data capture
Change Data Capture (CDC) streams events directly from a legacy database's transaction log, enabling gradual monolith decomposition without modifying the legacy code.
#8about 6 minutes
Achieving massive throughput with sharded architectures
Sharding partitions data and processing across independent streams, enabling systems to scale horizontally and handle nearly unlimited throughput.
#9about 3 minutes
Balancing architectural complexity and business needs
Evolving from a monolith to a sharded, stream-based system adds powerful capabilities but also increases complexity, so always choose the simplest architecture that meets your requirements.
#10about 3 minutes
Answering questions on micro-frontends and data ownership
The speaker discusses how micro-frontends align with team autonomy and clarifies that while data can be copied to projections, updates must go through the owning service.
Related jobs
Jobs that call for the skills explored in this talk.
Matching moments
07:20 MIN
Tracing the evolution of microservices toward reactivity
Rethinking Reactive Architectures with GraphQL
01:32 MIN
Understanding the principles of reactive architecture
Architectures that we can use with .NET
08:28 MIN
Applying reactive principles to system architecture
Rethinking Reactive Architectures with GraphQL
05:40 MIN
Evolving from classic microservices to event-driven design
Kafka Streams Microservices
02:07 MIN
Meeting modern application demands with the Reactive Manifesto
Is reactive the new black? Imperative vs. reactive programming with Quarkus
02:23 MIN
Core principles of the reactive manifesto
Development of reactive applications with Quarkus
05:37 MIN
Understanding the core principles of the reactive manifesto
Side-by-Side: Reactive vs non-reactive Java
06:43 MIN
Building an event-based microservice architecture for agility
Why You Shouldn’t Build a Microservice ArchitectureWelcome to this issue of the WeAreDevelopers Live Talk series. This article recaps an interesting talk by Michael Eisenbart who talks about the pros and cons of microservice architecture.About the speaker:Michael has been working for Bosch as a sof...
Micro Components - a different approach to a simpler component-based webThere has been a lot of heated discussion lately in the web community about component based development. One side argued that Web Components are a standard we should follow whereas others complained that they still lag behind in what frameworks offer...