# On the Design of Distributed Programming Models

**Authors:** Christopher S. Meiklejohn

arXiv: 1701.07615 · 2017-02-02

## TL;DR

This paper explores the design space of distributed programming models, introducing Lasp, Austere, and Spry, which address the tradeoffs between consistency and availability in large-scale systems.

## Contribution

It presents two novel programming models, Lasp and Austere, demonstrating the bounds of distributed model design and proposing Spry for declarative consistency tradeoffs.

## Key findings

- Lasp and Austere exemplify strict AP and CP tradeoffs.
- Distributed models must navigate the CAP theorem constraints.
- Spry enables declarative specification of consistency levels.

## Abstract

Programming large-scale distributed applications requires new abstractions and models to be done well. We demonstrate that these models are possible.   Following from both the FLP result and CAP theorem, we show that concurrent programming models are necessary, but not sufficient, in the construction of large-scale distributed systems because of the problem of failure and network partitions: languages need to be able to capture and encode the tradeoffs between consistency and availability.   We present two programming models, Lasp and Austere, each of which makes a strong tradeoff with respects to the CAP theorem. These two models outline the bounds of distributed model design: strictly AP or strictly CP. We argue that all possible distributed programming models must come from this design space, and present one practical design that allows declarative specification of consistency tradeoffs, called Spry.

## Full text

_Full body text omitted from this summary view._ Fetch the complete paper as Markdown: https://tomesphere.com/paper/1701.07615/full.md

## Figures

1 figure with captions in the complete paper: https://tomesphere.com/paper/1701.07615/full.md

## References

32 references — full list in the complete paper: https://tomesphere.com/paper/1701.07615/full.md

---
Source: https://tomesphere.com/paper/1701.07615