Code Challenge: Backend and DevOps

A sample microservice backend project with Django, Redis and Kafka for testing familiarities with these tools.

Included in the Box

A sample data fetching service called data_from_tsetmc that fetches stock price data from the official website of Tehran Stock Exchange (TSE) is found in ./services folder. In ./redis folder there is a docker-compose file for running a dockerized Redis database instance. Similarly, the docker-compose file for starting a dockerized instance of message queuing system Kafka is found in ./kafka folder.

Backend Design

The backend architecture is based on a microservice structure. Django provides the API endpoints and some of the business logics, utilizing both PostgreSQL and Redis database. The message queueing is carried out by Apache Kafka as the message broker. The rest of business logics are done with the help of different services that are connected to Kafka.

Step 1: Resilient Micro-Service

The first step is to emulate a typical data flow in a microservice structure. The goal is to have the data_from_tsetmc service fetch the stock price data from the web every minute and publish them to Kafka. Simultaneously, a second service should consume these messages and updates the list of price data for each stock in Redis.

First, tweak the data_from_tsetmc so that it publishes the data it receives from the web to a topic in Kafka. Afterwards, create a separate service that reads the price data records and updates the price list for each stock in Redis.

Zooming in the provided service data_from_tsetmc.py, you might have noticed that it needs some improvements. What are your suggestions to improve the quality of this code and also its function so that it can be used in a production environment?

At this point the data flow of stock price data is working properly, however it is still not production-ready. We want to consider HA (High Availability) and DR(Disaster Recovery) for our service. Let's assume there is a chance that our service is forcefully shut down and restarted. Moreover, the whole server can fail and shutdown. It is important for us to make sure that after the crash no data is lost, additionally, the services should compensate for the time they were down and we should have the data exactly from where they left off last time.

Discussion: What would be some of the steps you would take regarding the setup of Kafka brokers and the coding of each service to ensure HA and DR?

Finally, dockerize the scripts to be used as standalone services.

Step 2: Django and DRF: Requests Inception!

The goal in this step is to create a BuyStock API endpoint in Django and perform some checks on the request.

Start an empty Django project and make sure rest_framework is installed. Create an API endpoint named BuyStock which accepts a Post request from user. The body content is a valid json object in this form as an example:

{ 
	"user": "user2", 
	"stockid": 44891482026867833, 
	"quantity" : 100 
}

This request needs to be verified and a proper response needs to be sent back.

First we need to make sure the user has enough credit to buy this stock. Connect to the Redis database and get the user data for this user. If the user credit is not enough to buy this stock in this quantity return Deny: Not enough credit. If the user has enough credit, we need a to perform a second (fictional) check.

Let's imagine that for each user request, we need to call an external API ourselves to verify the state of the user. The problem is that this external API call might take long to respond or might even stall. Here, for simplicity, we simulate this API call with this simple function:

def verify_user(user_id):
	time.sleep(random.randint(1,100))
	return True

Here, the API call might take anytime between 1 to 100 second to respond, but in reality, if the request takes longer than 60 seconds, it has stalled and should be stopped.

Now, complete the API endpoint to have these functionalities:

• the user should immediately get notified of successful reception of their buy request, i.e. they should instantly know that we have received their request and we have checked their credit. The user receives Deny: Not enough credit if they don't have enough credit. If their credit is sufficient, they receive In Progress: Credit check passed. User verification in progress...

• The user should be able to get the final result with the least amount of delay after the verification is complete. The final result is either Success: Buy order complete. or Failure: User verification unsuccessful.

Note: Preferably make use of the already implemented stacks in the backend structure

Discussion: Think about the different tests you would write for this web app to make sure it is working properly. Implement one of them.

Step 3: CI/CD!

Note: Continue with this part only if you are interested in CI/CD and software deployment.

Let's imagine the Django web application in Step 2 is now completed with various API endpoints, connection to PostgreSQL and Redis for database and cache, and connection to Kafka as the message broker. Moreover, various services are working alongside the Django app for different backend tasks. These are all currently in development state. However, they need to be prepared for deployment.

Discussion: In your opinion, what steps are necessary to deploy a production-ready version of the described stack? As an example, what are some of the choices you would make regarding these different approaches: VM/Docker, WSGI/ASGI, Gunicorn/Daphne, Docker-Compose/Docker-Swarm/Kubernetes