Distributed systems exist in all shapes and sizes, and chances are you're either working on one now. But the fundamental nature of distributed systems means that we are exposed to all sorts of problems that can cause our systems to become slow, unresponsive, or even fail altogether.

In this one day class, you'll learn about the challenges of distributed systems, and what you can do to create software that is much more likely to work when users need it to.

Whether you're building a fine-grained microservice architecture, or a more monolithic distributed system, you'll learn concrete practices to help make your software more robust.

This is not a coding matserclass, but it is interactive. This is a class about concrete practice, but presented in a technology agnostic way.

What We Will Cover:

Each class is different, with the attendees shaping what content we will cover in each class, but expect to cover:

• What is resiliency?
• The Golden Rules of distributed systems
• Timeout tuning
• Retires & Idempotency
• Load shedding & back pressure
• Circuit breakers
• Bulkheads
• CAP Theory

Architecture is all about the boxes and arrows. Whilst the boxes themselves can be interesting, it’s the arrows between them that this class will focus on. How can microservices communicate with each other?

No two classes are the same, with the attendees driving the exact agenda, but expect to cover the nature of synchronous and asynchronous communication, request-response vs event-driven collaboration, and why friends don’t let friends use distributed transactions. Along the way we can talk about the merits of different types of message brokers, why Sam now thinks schemas are cool again, and how event sourcing can be incredibly confusing.

Please note, this is not a coding class, but it is highly interactive. There will be lots of discussion - computing is all about trade offs, and this is especially true in the space of microservice communication. There is no one perfect solution, but by the end of the class you’ll better understand what trade offs might be important to you.

Distributed systems exist in all shapes and sizes, and chances are you're either working on one now. But the fundamental nature of distributed systems means that we are exposed to all sorts of problems that can cause our systems to become slow, unresponsive, or even fail altogether.

In this one day class, you'll learn about the challenges of distributed systems, and what you can do to create software that is much more likely to work when users need it to.

Whether you're building a fine-grained microservice architecture, or a more monolithic distributed system, you'll learn concrete practices to help make your software more robust.

This is not a coding matserclass, but it is interactive. This is a class about concrete practice, but presented in a technology agnostic way.

What We Will Cover:

Each class is different, with the attendees shaping what content we will cover in each class, but expect to cover:

• What is resiliency?
• The Golden Rules of distributed systems
• Timeout tuning
• Retires & Idempotency
• Load shedding & back pressure
• Circuit breakers
• Bulkheads
• CAP Theory

Architecture is all about the boxes and arrows. Whilst the boxes themselves can be interesting, it’s the arrows between them that this class will focus on. How can microservices communicate with each other?

No two classes are the same, with the attendees driving the exact agenda, but expect to cover the nature of synchronous and asynchronous communication, request-response vs event-driven collaboration, and why friends don’t let friends use distributed transactions. Along the way we can talk about the merits of different types of message brokers, why Sam now thinks schemas are cool again, and how event sourcing can be incredibly confusing.

Please note, this is not a coding class, but it is highly interactive. There will be lots of discussion - computing is all about trade offs, and this is especially true in the space of microservice communication. There is no one perfect solution, but by the end of the class you’ll better understand what trade offs might be important to you.

Architecture is all about the boxes and arrows. Whilst the boxes themselves can be interesting, it’s the arrows between them that this class will focus on. How can microservices communicate with each other?

No two classes are the same, with the attendees driving the exact agenda, but expect to cover the nature of synchronous and asynchronous communication, request-response vs event-driven collaboration, and why friends don’t let friends use distributed transactions. Along the way we can talk about the merits of different types of message brokers, why Sam now thinks schemas are cool again, and how event sourcing can be incredibly confusing.

Please note, this is not a coding class, but it is highly interactive. There will be lots of discussion - computing is all about trade offs, and this is especially true in the space of microservice communication. There is no one perfect solution, but by the end of the class you’ll better understand what trade offs might be important to you.

Distributed systems exist in all shapes and sizes, and chances are you're either working on one now. But the fundamental nature of distributed systems means that we are exposed to all sorts of problems that can cause our systems to become slow, unresponsive, or even fail altogether.

In this one day class, you'll learn about the challenges of distributed systems, and what you can do to create software that is much more likely to work when users need it to.

Whether you're building a fine-grained microservice architecture, or a more monolithic distributed system, you'll learn concrete practices to help make your software more robust.

This is not a coding matserclass, but it is interactive. This is a class about concrete practice, but presented in a technology agnostic way.

What We Will Cover:

Each class is different, with the attendees shaping what content we will cover in each class, but expect to cover:

• What is resiliency?
• The Golden Rules of distributed systems
• Timeout tuning
• Retires & Idempotency
• Load shedding & back pressure
• Circuit breakers
• Bulkheads
• CAP Theory