Join for free and connect with our local tech scene

Stay on top of the latest companies and upcoming events with our weekly newsletter, and be counted among the people building the future of your local tech community.

Phoenix, AZ /

Build a Database Server

Galvanize 515 East Grant Street, Phoenix, Arizona, 85004 , Phoenix, AZ (map)

Hey everyone! Super excited for this meetup. For October, we'll be building a key/value database server. This is an adaptation from an interview challenge from a well known company who writes a lot of Go.

We will spend the first portion of the evening going over our implementations and helping others who haven't quite finished theirs or are looking to learn from what others have done. We'll spend the last half of the evening presenting our implementations and running some benchmarks.

You're free to use whatever tools are available to build this.

Requirements:

1. Listen on port 8888

2. Handle the following commands: GET, SET, DEL, QUIT, BEGIN, COMMIT. All commands need to be terminated with a "\r\n" string.

3. Must support transactions. Transactions should be a N+1 queries grouped together to operate on the data, segmented off from other transactions.

Non-transactional Command Specifications:

1. GET - key -> returns ; GET takes a string key and returns the value if it exists otherwise an empty string.

2. SET - key, value -> returns ; SET takes a string for a key and a string for a value and returns a string. The return string will be "OK" on success or contain an error.

3. DEL - key; DEL takes a string for the key and removes that entry. The return string will be "OK" on success or contain an error.

4. QUIT - kills the active connection

Transactional Command Specifications:

1. BEGIN - BEGIN indicates to the server that you want to use a transaction and to start one. All commands following will be scoped to that transaction.

2. COMMIT - COMMIT indicates that the transaction is complete and to finalize the transaction by committing any changes to the global data store.

Examples:

Regular interaction with the server:

SET key1 value1\r\n

GET key1\r\n

DEL key1\r\n

QUIT\r\n

In the example above, the expectation is that if "key1" doens't exist, it is created and the "value1" is assinged to it. If it already exists, "key1" is updated with the new value.

Transactional interaction with the server:

BEGIN\r\n

SET key1 value1\r\n

GET key1\r\n

DEL key1\r\n

COMMIT\r\n

QUIT\r\n

In the example above, the expectation is that a new transaction is started which will cause all of the queries below to operate on their own set of data. That means that the same expectations apply from the first example however those changes aren't seen outside of the scope of the transaction. If "key1" is set, then deleted, another transaction could be performing operations on "key1" at the same time however only the transaction that gets committed is seen.

Feel free to post any questions about this here or on twitter: @golangphoenix

Comments

Sign in to comment.