Hi, a warm welcome to tech-maze, in today's article we will explore how an on-demand courier service app works and how many necessary functionality at minimum level it should provide to its customer.
When we think about on-demand courier service, many functionality comes in our mind, out of these, few related to how on-demand courier service app fulfill customer requirements and few related to how backend system supports application flawlessly
lets categorize and explore these requirements in two subsets, functional and non-functional
Functional
user registration - a user can register himself/herself
place the order - a registered user can place the order
track the order - registered user can track the order in real-time
check the current status - registered/guest user can check current status
user profile/dashboard - - a registered user can update the profile, check activity history etc.
Non - Functional
No downtime - app must always be reachable
Fault Tolerant - no request should be rejected even during peak time or during server failure
Consistency - balancing the load
No single point of failure - few server fails then rest of the server must serve the request and also bring additional server in no time if needed
Lets check following steps to determine how above diagram reflects the process of serving the request
Step 1 - user opens the application
Step 2 - application opens with options login/register and check package status
Step 3 - if user has delivery id number then he can check the status by providing delivery id in check package status option, request will go to CDN and it fetches the current status and send the response back to user, in this case user don't have to login.
Step 4 - user can also check the current status of the order by login to the application, if user is new then he/she can register himself/herself to explore all the services.
UserRegistrationService provide the functionality of registering a new user and save the data in database.
Step 5 - user provide credential and login to the app, login credentials validated at the api gateway, on successful validation, request forwards to UserDetailsService
Step 6 - user details displays on the screen with lot of other options such as estimate the delivery charge, place an order, profile details, activity history etc.
Step 7 - user selects place an order and fill the form with all the details such as, to address, from address, estimates weight, name, contact details etc.
upon filing all the options total charge displays on user screen and ask user to proceed with payment
this process is taken care by OrderService
here OrderService saves the information provided by the User in database.
Step 8 - user select the payment option and click on submit
OrderService calls payment service and on successful response, shows success message to User along with estimated time of delivery with unique tracking id/delivery id.
This generated tracking id/delivery id will be saved in database along with package details.
Here ordering process completes, now we have to take care one more steps which is when package delivered to the client.
So when package marked as delivered in database, this details will move to another table which maintains the history of all delivered packages for the logged in user, this steps actually reduce the load from the actively participating tables from placing the order to delivery of the package.
So we have seen the flow of request from technical point of view, lets checkout non-functional requirement such as fault tolerance, no single point of failure etc.
We can have following two types of user
Guest/New user --
A guest user can check the current status of the goods, for other services, user has to login or register
Guest user's request forward to CDN and CDN returns the current status of the goods based on tracking id
For Registered User --
A registered user can
check the current status of the goods
check the traces of goods movement.
select the delivery choice
place the order
update his/her profile
see history of placed orders
In on demand courier service, write is outnumbered by read, that is most of the time user check the status instead of placing the order hence we can have more instances for that service which brings the user details, goods status, order history etc., this information can be cached for fast retrieval.
Registered user's request goes via API gateway, API gateway authenticate the user, on successful, request goes to Load balancer now Load balancer decides which server should serve this request based on the implemented algorithms such as round robin, weighted round robin, least connection, least time etc.
To know more about load balancing technique, checkout my previous article on load balancing and consistent hashing, link provided at the end of this article.
These servers host microservices instances, and one of the eligible service instance start processing the request, details can be fetched either from database or cache memory depends on the availability of data, and if request came for placing an order or registering a user then data will be saved in database and then sync with cache memory.
For syncing, database and cache memory we can use one among these techniques "write-through" or "write-back", i will explain both the technique in my upcoming article, for now just understand, these techniques are used to make database and cache memory in sync with the updated data.
Sharding technique can be used for fast processing of data, sharding is a technique where partition is done based on data such as details for user id 1-5000 will be in one partition, 5001 to 10000 will be in another partition and so on, so that a user request (suppose user id is 100) should always go to one of the partition, for redirection of the request, indexing or schema based rule can be used.
Since we don't have to overload load balancer with response processing and authentication as request has already been validated, server can send response directly via API gateway to client.
This is one the approach or starting point of having a consistent on-demand courier service design, this approach can further be improved based on the complexity of the system, but basic approach should be something like this.
That's all folks in this article, keep visiting, feel free to share this article and share your suggestion/thoughts or any other approach in comment section.
A Big thank you for checking out my article, this really encourage me to come up with more topics.
Here are some resources you might be interested ------------------------
コメント