System Design Capstone (SDC) Project

Table of Contents

• Requirements
• Chosen Optimization Path
• Results
  • Methodology
  • Test Results
  • Recommendation
• Technologies

Requirements (Back to Top)

• Gather metrics about the current performance of the application
• Research and experiment with methods of optimizing and scaling the application
• Take detailed notes on all your work and findings in the engineering journal
• Report the results on a written and video format

Chosen Optimization Path (Back to Top)

API Optimization through the use of a load balancer (Nginx).

Final testing architecture:

Results (Back to Top)

I set out to answer the following questions for the client:

1. What are the API endpoints’ performance under the current configuration?
2. What are some ways key metrics such as latency, throughput, and availability, can be improved?

Methodology: (Back to Top)

The methodology for the tests was relatively simple; gather baseline metrics on Server 1 and Server 2 independent from each other, then deploy the Nginx load balancer and test again, analyze the results, and provide recommendations.

Test Results: (Back to Top)

Both Server 1 and Server 1 results were relatively close to each other. Server 1 averaged 633.9 http requests per second (RPS) while Server 2 averaged 643.2 RPS. Latency under 500ms per http request was also close on both servers, able to achieve this in average for 700-800 VUs. In summary, they were able to easily handle the estimated normal load of 300 VUs with latency under 200ms per http request, but struggled with more than 800 VUs, maxing their throughput around 650 RPS.

The last phase of testing against the Nginx load balancer revealed promising results considering horizontal scaling was limited to the addition of only one server. Load balancing increased the average throughput of the system to 1,062 RPS from 650 RPS utilizing one server (63% improvement), and increased the maximum amount of VUs from 700-800 to 1300-1400 (86% improvement) while maintaining average latency of http requests under 500ms, all without compromising availability as error rate remained zero across the board.

Recommendation (Back to Top)

Based on the results above, I encouraged the client to consider scaling horizontally to at least one more server. The ‘new normal’ with one load balancer between two low-power servers increased to 700 VUs (133% improvement), with a throughput of 1050 RPS (63% improvement), at the same baseline latency of 200ms and zero req. errors.

Read the full report here...

Watch the capstone video here...

Technologies (Back to Top)

----- Original README file of the project to optimize -----

Front End Capstone Project: AirBnB Clone (ChairBnB)

Tech Stack

Objectives & Minimum Requirements

• Build a Full Stack UI Clone of an app's "item detail page"
• Page must contain multiple distinct modules of functionality
• Selected App should have sufficient complexity
• Implement React Components
• Perform API requests

Table of Contents

• ChairBnB Wireframe: Chairbnb Wireframe on Excalidraw
• Completed project here : [Coming Soon]

Installation & Setup

• Fork/Clone down this repo: ChairBnB
• cd into the project folder

npm install
cd server/
npm install
cd ..
cd client
npm install
cd ..
docker-compose up -d

• create a .env file in the server directory and add a key to point to the running docker container DATABASE=postgres://postgres:docker@localhost:5432/chairbnb

• create a .env file in the client folder and add a key for the Google Maps Api. VITE_API_KEY="your api key"

npm start

• Connect to the site in your browser 'http://localhost:5173/1'
• Note: You must have the /1 to see the product page. You can also use 2-4 to see different pages.

Collaborators

• Matthew Drevon - @MDrevon
• Joe Goralczyk - @joegor85
• Joshua Benton - @josh-benton
• Caleb Beam - @calebbeam
• Blake Barkman - @BlakesHere