Skip to content

Instantly share code, notes, and snippets.

@alberts

alberts/storagecodingchallenge.md

Forked from sargun/storagecodingchallenge.md
Created January 11, 2017 17:50
Show Gist options
  • Save alberts/76eb2895ba824cbb3d03cb341488370d to your computer and use it in GitHub Desktop.
Save alberts/76eb2895ba824cbb3d03cb341488370d to your computer and use it in GitHub Desktop.
Download ZIP
Raw
storagecodingchallenge.md

CODING OPPORTUNITY: Mesosphere Storage server

Your challenge, should you choose to accept it, involves building a storage service. The storage server is meant to store arbitrary data. You are to build a REST API (HTTP/1.1, or 2.0, your choice) that presents a data storage, and retrieval API.

Environment

Your environment runs on Ubuntu 16.04 in a Docker container as a non-root user. You are allowed to write to the current working directory.

You are to build your deliverable so that it extracts into the following layout:

challenge
challenge/bin
challenge/bin/challenge-executable
challenge/...

The working directory we will execute from is the directory directly above challenge. If you need us to set any environment variables, let us know.

You are to provide a compressed artifact (tar, with gz, bz2) that contains only one folder 'challenge'.

API

We will execute ./challenge/bin/challenge-executable. You are to bind to 0.0.0.0:7777 and provide the following API:

* POST /store/<location> - Create new blob at location
* PUT /store/<location> - Update, or replace blob
* GET /store/<location> - Get blob
* DELETE /store/<location> - Delete blob

Try your best to be as "resty" as possible. For example, if someone does a DELETE on a blob that doesn't exist, return a 404.

Priorities

When attacking this problem, we realize there is a lot of work to do, so we've prioritized features, like a good product manager might. Please implement all of 1 before moving to 2, and all of 2 before moving to 3, etc...

  1. Implement the above API
  2. Be able to be restarted
  3. Be crash-tolerant
  4. Be tolerant to as many other failures you can think about.

Compromises

A lot of software engineering is about compromise. If you find that crash-tolerance is very difficult, let us know, and explain why it's very difficult, and how you might implement it. We test the API, but as long as the change is within reason, we should be able to adapt the tests.

Notes

  • You should assume that the number of blobs will be <10k, and that there will be more than enough memory on the machine that it will not be a problem.
  • No need to be tolerant to disk, or fundamental OS failure
  • Think about error conditions, like a stream being interrupted, or filling up the disk
  • You should have tested your code
    • We will run your tests, in addition to our own
  • Feel free to write a design document
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment