Message Queues
--------------
Your task is to design and implement a message queue.

IMPORTANT
---------
Please take the time to read this document carefully before commencing. In
particular, please note the section titled "What we are looking for" below.


Background
----------
Message queues are a ubiquitous mechanism for achieving horizontal scalability.
However, many production message services (e.g., Amazon's SQS) do not come with
an offline implementation suitable for local development and testing.  The
context of this task is to resolve this deficiency by designing a simple
message-queue API that supports three implementations:

 - an in-memory queue, suitable for same-JVM producers and consumers;

 - a file-based queue, suitable for same-host producers and consumers, but
   potentially different JVMs; and

 - an adapter for a production queue service, such as SQS.

The intended usage is that application components be written to use queues via
a common interface, and injected with an instance suitable for the environment
in which that component is running (development, testing, integration-testing,
staging, production, etc).

For further background reading on the idea of providing local implementations of
production systems, please read:

https://engineering.canva.com/2015/03/25/hermeticity/


Behavior
--------
If message queues are an unfamiliar concept, see SQS docs for a description of
how they are intended to behave.  In particular, note the following properties:

 - multiplicity
   A queue supports many producers and many consumers.

 - delivery
   A queue strives to deliver each message exactly once to exactly one consumer,
   but guarantees at-least once delivery (it can re-deliver a message to a
   consumer, or deliver a message to multiple consumers, in rare cases).

 - order
   A queue strives to deliver messages in FIFO order, but makes no guarantee
   about delivery order.

 - reliability
   When a consumer receives a message, it is not removed from the queue.
   Instead, it is temporarily suppressed (becomes "invisible").  If the consumer
   that received the message does not subsequently delete it within within a
   timeout period (the "visibility timeout"), the message automatically becomes
   visible at the head of the queue again, ready to be delivered to another
   consumer.


Scope
-----
You have 4 tasks to complete:

1. write a QueueService interface to cater for just the essential actions:
   - push     pushes a single message onto a specified queue
   - pull     receives a single message from a specified queue
   - delete   deletes a received message

2. implement an in-memory version of QueueService; The in-memory version should
   be thread-safe.

3. (optional, time permitting) implement a file-based version of the interface,
   which uses file system to co-ordinate between producers and consumers in
   different JVMs (i.e. thread-safe in a single VM, but also inter-process safe
   when used concurrently in multiple VMs); and

4. (optional, time permitting) implement an sqs-based version of the interface.

If you find yourself running low on time, we'd appreciate at least a description
of how you would implement the outstanding tasks (in comment form, in the
relevant source files).

You should:
 - allow 4-6 hours for this task;
 - don't be afraid of a simple solution if you can find one;
 - include unit tests (in particular, you should test the behavior of the
   visibility timeout);
 - based on the intended usage of the implementations, you should use your
   judgement to make trade-offs between competing factors, such as performance
   vs simplicity;
 - include comments where relevant (pretend you are submitting this as a pull
   request); and
 - not require any additional libraries (Guava, Junit, and Mockito have been
   provided, but you may switch to use Apache Commons if you prefer).


Building and Running
--------------------
You should be able to import this project into any conventional IDE as a Maven
project. As a fallback, you can use Maven to build and run tests from the
command-line with:
  mvn package


What we are looking for
-----------------------
- The entire implementation shouldn't really need more than 7-10
  classes, tests included.
- The in-memory solution should be thread safe.
- The file-based solution should be thread safe and inter-process safe when run
  in a *nix environment. See https://engineering.canva.com/2015/03/25/hermeticity/
  for a description of how to achieve this.
- We expect unit tests that
  - are deterministic
  - have fast running time (< 1 sec)
  - meaningfully test all interface methods of your queue service
  - test the visibility timeout. Try and construct effective tests that don't
    rely on physical time or thread sleeping.


Submission Checklist
--------------------
Your submission should:
 - compile as submitted (please only JDK 7 or JDK 8)
 - have passing unit tests
 - be zipped/archived with a top level directory that identifies you by name