Skip to content

maxisch/interview-challenge

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

4 Commits
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Objective and Context

The goal of this exercise is to implement in python3.7 a microservice performing read/write operations to a MySQL database. The difficult part of the challenge is to handle concurrent requests without losing consistency of the data.

This service is exposed using uwsgi which creates 4 worker processes to handle concurrent requests. I chose Flask as the web framework to integrate with uwsgi

Prerequisites:

This project does not include a migration mechanism such as Flask-Migrate. There is at the root of the project a file called init_db.sql with the SQL DDL queries to initialize the database. This is a manual step.

Starting the application

Build and run the application using docker-compose. The .env file is included for demonstrational purposes, as .env files should not be versioned.

docker-compose build api client
docker-compose up mysql
docker-compose up api

To use the API on your localhost, you need to bind the ports. Add the following line to your api definition in the docker-compose.yml and rebuild

ports:
  - 8888:8888

Running the tests

To run the tests execute:

docker-compose up client

Which should output the following:

docker-compose up client
Docker Compose is now in the Docker CLI, try `docker compose up`

interview-challenge_mysql_1 is up-to-date
interview-challenge_api_1 is up-to-date
Starting interview-challenge_client_1 ... done
Attaching to interview-challenge_client_1
client_1  | test_0_health (api_test.ApiTestCase)
client_1  | anity check to ensure that the API is reachable ... ok
client_1  | test_1_single_user (api_test.ApiTestCase)
client_1  | test read/write operations on a single user ... ok
client_1  | test_2_two_users (api_test.ApiTestCase)
client_1  | test read/write operations with two users ... ok
client_1  | test_3_concurrent (api_test.ApiTestCase)
client_1  | test concurrent read/write operations with multiple threads ... ok
client_1  |
client_1  | ----------------------------------------------------------------------
client_1  | Ran 4 tests in 0.430s
client_1  |
client_1  | OK
interview-challenge_client_1 exited with code 0

Lessons learned

On my first approach, I solved the concurrent update in a very convoluted way, which lead into inconsistent test runs. I had some green runs, and some red runs on the fourth test, which failed because of deadlocks. Upon closer inspection and rethinking my query, I came up with the proposed solution, which decoupled the involved tables in the deadlocks.

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published