Skip to main content.

Project 2: Tiny Bookstore Project

Checkout project by Wednesday, October 4
Preliminary Deadline: Monday, October 16 - (at least) completed synchronized server-side code, with (basic) client implementation, preliminary testing of system. Code should be pushed to GitHub. Tag this version with preliminary_implementation
Final Deadline: Tuesday, October 24 - evaluation scripts, graphing, write up, testing, fixing any issues uncovered by continued work.

This project has two goals:

  1. to help you gain experience with remote procedure calls, from the perspective of the client and the server.
  2. to teach you about the design and internals of a multi-tier distributed system

This project should be done in teams of two.

Part 0: Set Up

Part 1: Build the Store

You have been tasked to design - the World's smallest online bookstore. carries only four books:

Since hopes to one day become the next Amazon, they would like to use sound design principles to design their online store in order to allow for future growth.

The store will employ a two-tier design: a front-end and a back-end. The front-end tier will accept user requests and perform initial processing. The backend consists of two components: a catalog server and an order server. The catalog server maintains the catalog (which currently consists of the above four entries). For each entry, it maintains the number of items in stock, cost of the book (you can pick the price), and the topic of the book. Currently all books belong to one of two topics: distributed systems (first two books) and college life (the last two books). The order server maintains a list of all orders received for the books.

The front end server supports three operations:

The first two operations trigger queries on the catalog server. The buy operation triggers a request to the order server.

The catalog server supports two operations: query and update. Two types of queries are supported: query-by-subject and query-by-item. In the first case, a topic is specified and the server returns all matching entries. In the second case, an item number is specified and all relevant details are returned. The update operation allows the cost of an item to be updated or the number of items in stock to be increased or decreased. You can implement update as either one or two procedures.

The order server supports a single operation: buy(item_number). Upon receiving a buy request, the order server must first verify that the item is in stock by querying the catalog server and then decrement the number of items in stock by one. (Note: what could happen if you would try to implement the previous statement as two separate function calls?) The buy request can fail if the item is out of stock. Assume that new stock arrives periodically (you can pick the interval--easier to add more inventory and increase the interval) and the catalog is updated accordingly.

The client program should allow users to test all functionality in the order they desire.

A pictorial representation of the system is as shown in the figure below.

Other requirements:

No GUIs are required. Simple text-based interfaces are fine.


Hopefully, you followed good design principles and built the system up incrementally.

How can you test the system to make sure that your system is properly synchronized? Do your best to put your system into the worst-case scenario.

Part 2: Evaluation

It's time for the all-important evaluation of your system. Design experiments and scripts to do the following:

  1. Compute the average response time per client search request by measuring the response time seen by a client for 500 sequential requests.
  2. Compute the average response time per buy request for 500 sequential requests.
  3. Rerun experiments 1) and 2) with multiple clients concurrently making requests to the system. Does your average response time change as the number of concurrent requests changes?


Part 3: Write up

After implementing, write a document that describes your system. You should describe the data structures you used and how you synchronized. Include any assumptions that you made (e.g., about the restock), along with any problems that you were unable to solve. Discuss how you tested. Finally, you should describe your experimental setup and graphs to support your answers to the evaluation questions.

Part 4: Submission

GitHub Classroom will make a snapshot of your repository at the deadline. Your repository should contain:

  1. Your writeup (as a PDF).
  2. All the files for your source code
  3. A copy of the output generated by running your program. When a client purchases a book, have your program print a message "bought book book_name". When a client issues a query (lookup/search), have your program print the returned results in a nicely formatted manner.


I have collected some resources to help you get started with various aspects of this assignment:

Graphing for Evaluation

Maybe Helpful Hints