Architecture of our site

Our server-side application will be composed of a monolithic core, three services, MongoDB server, and image storage server.

The monolithic core will serve pages to the site visitors and administrators.

The three services are database service, URL configuration service, and upload service. The following is what each of these services do:

• Database service: Adding, retrieving, updating, and deleting coupons in MongoDB is done through database service. The monolithic core retrieves coupons from MongoDB through database service, and upload service stores coupons through database service.
• Upload service: When a user submits a coupon, the HTML form is submitted to the upload service. The upload service then sends the image to the image storage server and adds metadata about the coupon to the database using the database service. We moved these operations to a different service, because if we are resizing and converting the uploaded image, then it will consume more memory and CPU time and keep the port open for more time, which will flood the server and break the monolithic core in case there are a large number of submissions at a time, so moving these operations to a different service makes sure that if there is a rise in submissions, it doesn't affect the site visitors who are looking for the coupons. We won't be resizing and converting images, but if you want to add this functionality, you can add this by simply updating the upload service. While the upload service is being updated, the form submissions will not work, but everything else will work. Therefore, we can say that this functionality can be independently updated without affecting other functionalities.
• URL config service: The client communicates with the monolithic core, image storage server, and upload service. In a production site, these three servers will remain in three different physical computers with three different IP addresses. So, for the client to be able to communicate with them, these three need to be exposed via different domain names (that is the monolithic core can be pointed using the main domain and the other two using sub domains) or we can use a load balancer or reverse proxy that supports URL rerouting so that we can have a single domain name and route the requests to the respective server based on the path of the URL. The URL config service will serve the base URL to communicate with these three servers. To follow this chapter, you can simply run these servers in the same physical computer using different ports, and when you are ready to make the site live, you can change the base URLs in the URL config service, depending on what technique you used to make the client able to communicate with the servers. You don't have to modify the source code of the servers directly, which is a cumbersome and risky task.

We will be creating our own image storage server. However, in a production site, I would recommend that you use Amazon S3 or something similar to store images, as it makes it easy to serve images via CDN. You don't have to worry about scaling and reliability, and it's low cost. The image storage server that we will be creating will be a basic one to just demonstrate how to store images in a separate server and serve from there.

The following is the diagram that shows all the architecture's looks and how the servers in the architecture communicate with each other: