This article introduces the queuing coupon delivery requirements of a catering system, and the process of boundary division and technical implementation of the requirements.
1. Propose requirements
It is still the Internet catering system mentioned above, which provides the ability to queue up for restaurants.
Because there are too many people eating in some popular restaurants, there are many long queuing times, and people give up queuing to eat and go to other restaurants.
In order to retain these users, the restaurant puts forward a demand to issue coupons to users who wait in line for a long time.
The main content of the demand: Customers who have queued for more than 30 minutes and have not eaten yet will receive a 20% discount coupon.
2. Design and implementation
The catering system has been split into two modules:
- Queuing and calling service, responsible for number issuing, queuing and number calling
- Marketing activity service, responsible for coupon issuance, coupon verification and other businesses
2.1 Initial Design
The R&D staff made a preliminary design, and the implementation steps are as follows:
- The customer takes the number, and delivers the number information to the 30-minute delay queue;
- After the number is called, the status of the queuing number will be updated as having eaten or passing the number;
- Consumers of the delay queue, when the message is consumed (this number has passed 30 minutes)
- If the status of the number is not queuing, morally educate the message;
- If it is in the queue, call the coupon issuing API of the marketing service to issue coupons.
After the review, I asked a question about R&D. Is this requirement fixed? Is it possible to make changes?
R&D said that the current demand received is:
customers who have queued for more than 30 minutes and have not eaten yet
will be given a 20% discount coupon. Will it change later? I don’t know how it will change.
2.2 Business review
We assessed that different restaurants are unlikely to have the same time plan, and may also give different discounts;
then communicate with the product manager, and the product responds. This is the current user demand received, and changes may not be ruled out in the future.
If you wait If the time changes, for example, the time is changed from 30 minutes to 40 minutes, the queuing code needs to be changed and released;
if the discount is changed, such as the coupon type is changed to other coupons, the queuing code should also be changed and released;
then the queuing business and delivery The coupon business should not be put together. Creating coupons, issuing coupons, and canceling after verification should all be marketing service businesses;
therefore, the business boundary is reorganized and the design process is as follows:
There are no other problems in the review, no matter how the marketing activities change , there is no need to change the queuing side, and
it will be iterated and developed according to this process.
2.3 Further business sorting and optimization
Afterwards, I reviewed this business and found that there was another detail that was not considered at the time:
- If a customer participates in the queue but leaves without eating, should a coupon be given at this time?
After evaluation, it should not be given away, so the demand has been changed to that when dining, the coupons will be delivered after more than 30 minutes, so as to avoid users from plucking wool, haha.
In this way, there is no need to delay the queue, and only need to monitor and exclude service events to complete the requirements, and the technical complexity is reduced again! ! !
- The data needs to wait in the queue for 30 minutes. Sometimes it is troublesome to troubleshoot problems, and a queue retrieval tool is required;
- If the coupon is delivered after 40 minutes of dining, it becomes a delay queue requiring multiple different times, which is more complicated;
- The delay queue has the risk of data backlog. If there are too many customers, the delay queue may be out of memory;
The only disadvantage of this requirement change is that the user cannot see the coupon after waiting for 30 minutes, and must have a meal to see it.
This point can be solved through user guidance.
Therefore, the latest design process is as follows:
Note 1: In the figure above, the marketing service needs to call the API of the queuing service to query the queuing information. This API is ready-made, because the queuing service itself needs to provide an API for the client to query the queuing waiting information, including the queuing time and how many are still ahead. number and so on.
Note 2: There is a point of thought here. Is it possible to save the news of the start of queuing on the marketing service side, and then check the local queuing information and calculate the time when calling the number for dinner later?
The answer is no, for the following reasons:
- The queue may be canceled, and the marketing service will still need to consume the cancellation event. The logic becomes complicated, and there may be other changes, such as giving the number to another person, and manually modifying the queue start time;
- There is an extra queuing storage data for marketing, and the marketing service side also needs to consider the follow-up queuing data cleaning work.
3. Summary
Business proficient
In-depth understanding of the business, can correctly identify the business boundary, such as this demand for queuing coupons:
- Sending coupons is a marketing activity, which has nothing to do with queuing business in essence. It is similar to shipping after successful payment, but shipping is not a payment business;
- The creation, management, distribution, and write-off of marketing activities should all be within the business scope of marketing;
- Queuing information, including whether the queuing data is valid (cancelled) and queuing duration are all business categories of queuing services;
- Marketing services need to design activities, and it is necessary to understand some queuing services, such as queuing message types and queuing duration, but if you can’t get too involved, you don’t have to. For example, in this business, you don’t need to care about queuing cancellation information.
Single Responsibility, Less Coupling
From an implementation point of view, the ability to deliver coupons in the queuing service can be quickly developed and implemented,
but the biggest disadvantage is business coupling: queuing is mixed with marketing activities, which is not conducive to subsequent modification and expansion,
such as: queuing modification 45 minutes to send coupons, or 30 minutes to send fruit plates instead of coupons; for example, to distinguish between genders, men and women will receive different discounts, etc.;
The most important problem: marketing service is not a core service, but a value-added service, and queuing service should be a normal basic service, and the failure of peripheral services should not affect the basic service; as for the coupling business, if there is a problem with the coupon delivery business
, The queuing business may also be affected, the probability of failure is high, and users may run away if they cannot queue;
and if the marketing service fails, the restaurant can also solve it through offline discounts.