Home

|

1. What Is Peloton?
2. What Is Peloton For?
3. What Problem Does Peloton Solve?
4. What Design Principles Underlie Peloton?
5. How Does Peloton Accomplish Its Goals?

|images/peloton-logo.jpg| |:-----------|-----------:| ## What Is Peloton?

Short description about Peloton.

History of Peloton

Short history

The following links provide more context around Peloton and the challenges that it attempts to address:

• “Making Netflix API More Resilient”

## What Is Peloton For?

Peloton is designed to do the following:

• Give protection from and control over latency and failure from dependencies accessed (typically over the network) via third-party client libraries.

## What Problem Does Peloton Solve?

Small description.

Example: For example, for an application that depends on 30 services where each service has 99.99% uptime, here is what you can expect:

99.99³⁰ = 99.7% uptime
0.3% of 1 billion requests = 3,000,000 failures
2+ hours downtime/month even if all dependencies have excellent uptime.

Reality is generally worse.

Even when all dependencies perform well the aggregate impact of even 0.01% downtime on each of dozens of services equates to potentially hours a month of downtime if you do not engineer the whole system for resilience.

---

When everything is healthy the request flow can look like this:

images/soa-1-640.png

These issues are exacerbated when network access is performed through a third-party client — a “black box” where implementation details are hidden and can change at any time, and network or resource configurations are different for each client library and often difficult to monitor and change.

## What Design Principles Underlie Peloton?

Peloton works by:

• Preventing any single dependency from using up all container (such as Tomcat) user threads.

## How Does Peloton Accomplish Its Goals?

Peloton does this by:

• Wrapping all calls to external systems (or “dependencies”) in a PelotonCommand or PelotonObservableCommand object which typically executes within a separate thread (this is an example of the command pattern).

When you use Peloton to wrap each underlying dependency, the architecture as shown in diagrams above changes to resemble the following diagram. Each dependency is isolated from one other, restricted in the resources it can saturate when latency occurs, and covered in fallback logic that decides what response to make when any type of failure occurs in the dependency:

images/soa-4-isolation-640.png

Learn more about How It Works and How To Use.