Most mobile APP s will have function modules to do tasks and receive rewards. The purpose of this kind of demand is to cultivate user usage habits, improve user activity, get credit reward for completing tasks, exchange goods or charge charges through credit, WeChat and so on.
Draw up a requirement scenario (Fig.), outline: Add a small task Tab to the navigation at the bottom of APP, click Tab to see the progress and progress of the task, Click to complete the jump to the business interface to do the task, when the user completes the task and meets the requirements, task Tab needs a red dot to remind the user that there are currently rewards to be received, the user receives them and there are no rewards to be received at the moment.The motivation red dot disappeared, and the task completion progress and leadership status remained the same day, refreshing the next day.
Requirements need to be sorted out, details confirmed before development, and solutions designed to estimate development time. Here is a comb of the core content of the business:
Users want to complete tasks, they need to operate other business functions, such as: daily review task after successful review, novice task after topic focus, which involves core issues, tasks need to depend on other businesses
To ensure subsequent scalability, tasks need to support background management, configure task name, description, task type (daily, novice, activity), number of completions, number of bonus points, to complete jump uri, etc.
Users do not automatically receive rewards after completing tasks, they need to go to the task list and click to take actions. Navigation Tab requires a small red dot reminder when they can get them, and the user experience of product confirmation task completion and reminder can accept a short delay
- Users operate business multiple times or repeat operations (malicious concurrent requests to brush credit) to ensure that the task can only be completed once and only be rewarded once, requiring idempotency
- Tasks depend on other businesses and need to be decoupled without affecting the functionality and performance of other businesses
- Designing background can be managed for subsequent expansion
- Abstract task module, code abstract development
- Idempotency is required to accomplish tasks and gain
- High Availability
- Tasks involve relying on other businesses. Here we need to abstract a concept that users can accomplish this task by operating the business. We define this process as user completion task event trigger completion, such as comment event, compliment event, attention event, etc.
In the implementation scenario, we use asynchronous consumption queue method, rely on business interface to bury event reporting, report task events that users successfully operate business to the queue, then develop scripts for message consumption, process business logic and DB operations on task events triggered by users in messages, update user task progress and availability status, and respond to users (complete assignment)Red dot reminder), blueprint:
- Dependent Business Decoupling
- Depends on the business to report task events for successful users to the message queue, then the program consumes them asynchronously
- The solution solves the strong coupling between dependent businesses without affecting the performance of existing business-dependent interfaces.
- Highly available:
- Start multiprocess to consume queues by dispatching the system
- The process daemon system, which keeps the daemon alive, runs and restarts to record and view execution logs
- For example: gocron
- Message queue monitoring, unable to consume timely warning, ensure instantaneity, avoid long delay
- redis list
- ... ...
- Fault Tolerance and Compensation
- Queue consumption failures need to be logged and can be supplemented by another program based on the business scenario
- User operation business report task events unlimited number of times, to avoid users did not complete the task, allow users to retry to do the task, program consumption needs to control the task can only be completed once
- Start multiprocess to consume queues by dispatching the system
-- Task Table CREATE TABLE `task` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'Self-increasing', `icon` varchar(300) NOT NULL DEFAULT '' COMMENT 'Icon', `title` varchar(30) NOT NULL DEFAULT '' COMMENT 'Task Title', `type` tinyint(4) NOT NULL DEFAULT '0' COMMENT 'Task type, novice task=1,Daily Tasks=2', `event` int(11) NOT NULL DEFAULT '0' COMMENT 'Event', `des` varchar(30) NOT NULL DEFAULT '' COMMENT 'Task Description', `target_num` int(11) NOT NULL DEFAULT '0' COMMENT 'Target Quantity', `points` int(11) NOT NULL DEFAULT '0' COMMENT 'Gold coin', `sort` int(11) NOT NULL DEFAULT '0' COMMENT 'sort', `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT 'State 0=Offline, 1=Go online,-1=delete', `app_version` varchar(15) NOT NULL DEFAULT '' COMMENT 'app version number', `app_version_compare` varchar(10) NOT NULL DEFAULT '' COMMENT 'app Version number comparison operator', `operator` varchar(10) NOT NULL DEFAULT '' COMMENT 'Operator', `jump_uri` varchar(300) NOT NULL DEFAULT '' COMMENT 'Jump Protocol', `create_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 'Creation Time', `update_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 'Update Time', `event_begin` timestamp NOT NULL DEFAULT '1970-01-02 00:00:00' COMMENT 'Event Start Time', `event_end` timestamp NOT NULL DEFAULT '1970-01-02 00:00:00' COMMENT 'Event End Time', `task_begin` timestamp NOT NULL DEFAULT '1970-01-02 00:00:00' COMMENT 'Task Start Time', `task_end` timestamp NOT NULL DEFAULT '1970-01-02 00:00:00' COMMENT 'Task End Time', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- User Task Situation Table CREATE TABLE `user_task_case` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'User Task Status', `user_id` bigint(20) NOT NULL DEFAULT '0' COMMENT 'user ID', `task_id` int(11) NOT NULL DEFAULT '0' COMMENT 'task id', `task_type` int(11) NOT NULL DEFAULT '0' COMMENT 'Task type', `event` int(11) NOT NULL DEFAULT '0' COMMENT 'Event', `task_uni` varchar(30) NOT NULL DEFAULT '' COMMENT 'Task Unique Identification(Unique Constraint) ', `target_num` int(11) NOT NULL DEFAULT '0' COMMENT 'Target Quantity', `finish_num` int(11) NOT NULL DEFAULT '0' COMMENT 'Quantity Completed', `points` int(11) NOT NULL DEFAULT '0' COMMENT 'Number of gold coins available', `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT 'State 0=To be completed, 1=To be picked up, 2=Has been withdrawn', `finish_at` timestamp NOT NULL DEFAULT '1970-01-02 00:00:00' COMMENT 'Complete Task Time', `get_at` timestamp NOT NULL DEFAULT '1970-01-02 00:00:00' COMMENT 'Time of withdrawal', `create_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 'Creation Time', PRIMARY KEY (`id`), UNIQUE KEY `uni_user_id_task_uni` (`user_id`,`task_uni`) USING BTREE, ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='User Task Situation Table';
-- Update claim status, note: WHERE Conditions, Strong Checks UPDATE user_task_case SET `status`=2,finish_at=CURRENT_TIMESTAMP WHERE id=:id AND user_id=:user_id AND `status`=1 AND finish_num>=target_num
Table Key Field Description:
- Task Unique Identification
user_id and task_uni combined unique constraint index
- Daily Tasks:
- Task id_Task type_date
- The default is to do only once (novice/active tasks):
- Task ID (task_id)
- Daily Tasks:
- The unique constraint index of user_id and task_uni combination in the user_task_case table ensures that daily and one-time tasks cannot repeat INSERT when multiple processes consume event queues in parallel through the unique constraint of mysql
- Guarantee idempotency of claim through UPDATE's WHERE condition check
Product design related background when planning requirements, but not necessarily reasonable design, so here we need to assist the product to adjust the management background based on confirmed solutions, to ensure the subsequent expansion
- Oriented to abstract development, rational use of design patterns for subsequent expansion
Talking about the last year's insights, I participated in the development of new APP projects in the last year, started to build projects from 0, and watched DAU rise little by little, it is still quite a sense of accomplishment.
There has been a change in roles, and now I feel more like a project participant than a task executor, having a deep understanding of the product while completing business development.
Free time will also follow up on competitive research and user use comments or issues, and provide some suggestions on products from the user's perspective.
Subsequently, the solutions that encountered problems or common business scenarios in the development of new projects will be combed out for blog posting.
Started in Github: [