Design and Implementation of 58.com Invitation Business System Architecture

This article provides a detailed introduction to the architecture design and practical experience of the 58.com invitation business system. It covers the business background, overall architecture, core component design, and technical implementation details. Through platform‑based design and standardized practices, the system significantly improves development efficiency, delivery quality, and business reusability, providing strong technical support for large‑scale recruitment matching.

Background Introduction

The invitation system is an efficient job‑person matching mechanism within recruitment business, using recommendation technology to suggest suitable positions to job seekers and leveraging AI dialogue capabilities to guide both parties toward successful intent fulfillment.

From a technical perspective, a single invitation process can be divided into the following key steps: invitation trigger, dual‑side matching, effect control, message delivery, and AI dialogue. This article focuses on the design and implementation of the stages from trigger to message sending.

1. Technical Challenges

To support the above functions, we designed and implemented an event‑driven automated invitation platform. This system efficiently supports rapid growth and feature iteration of the invitation business. During its rollout and evolution, we faced many technical challenges, which can be summarized into three major categories.

1.1 Architecture Design

The system must adapt to diverse business scenarios with varying complexity and scale, especially in trigger timing and business flow handling. The key focus is on designing a highly extensible and definable process architecture. Important metrics include unified management capabilities across scenarios (trigger timing definition, configurable business flows, traffic distribution control, monitoring), traffic shaping for resource utilization, and concurrency performance.

1.2 Trigger Timing

Trigger timing is divided into two main categories:

Real‑time trigger: based on user behavior, with high real‑time requirements; tests show the highest conversion within 5 seconds.

Scheduled trigger: based on a user group at a specific time, generally lower conversion efficiency and less stringent timeliness.

1.3 Business Process Abstraction and Reuse

Both real‑time and scheduled triggers involve common business processes such as pre‑condition checks, user filtering, A/B experiments, effect control (e.g., frequency control and job verification), dual‑side matching, and message styling. The challenge is to abstract these functions into generic atomic capabilities and provide a unified interface and framework for orchestration and composition.

2. Overall Design

2.1 Overall Idea

Based on the business background, we designed a highly modular and standardized system architecture. The core idea is to start from an overall process definition and gradually refine it into specific atomic capability abstractions, achieving fine‑grained system abilities.

The design follows a standardized abstraction flow, forming a complete product‑development (R&D) and quality‑assurance (QA) collaboration process. This ensures modularity, extensibility, and significantly improves delivery efficiency and quality. The architecture diagram is shown below:

The modular and standardized design enables the system to handle complex business requirements while maintaining flexibility and maintainability. Each functional module can be developed, tested, and optimized independently, enhancing overall stability and performance.

2.2 Trigger Timing and Process Orchestration

The invitation system’s trigger mechanism is divided into real‑time and scheduled triggers, providing flexibility for various complex business scenarios.

Process orchestration is another key feature. It solves the problem of differing execution flows across business scenarios. Through abstraction and modular design, we achieve highly configurable process management, allowing rapid assembly and adjustment of processing flows without extensive code changes.

As illustrated in the architecture diagram, the orchestration module enables flexible definition and combination of processing steps, improving adaptability, maintainability, and scalability.

Detailed technical implementation of trigger mechanisms and process orchestration will be discussed in the third part.

3. Technical Framework Design

3.1 Trigger Timing

We previously mentioned two trigger categories: real‑time (user behavior) and offline scheduling (timed). Here we focus on the design of the real‑time trigger system.

3.1.1 Event‑Driven Service

In this design, user behavior is abstracted as an event and decoupled via asynchronous messaging. Core concepts include:

Event Source: generates events, typically user activity such as browsing or applying for a job.

Event Processor: receives events, handles intermediate storage, rule evaluation, and determines the set of delivery targets.

Event Target: the final action triggered by the event, i.e., the downstream processing flow.

The diagram shows the core flow of the event‑driven service. We define a standard event (event source) for each integration point. After the processor receives an event, it queries related data and rules, performs filtering, protocol conversion, and target delivery, optionally with delayed execution. The following example uses a user activity event.

1) Filtering Rules

We adopt a pre‑filter mechanism focusing on fields in the message body. For this scenario, we selected the Aviator rule engine, which offers:

Support for diverse data types, including numbers, strings, regex, booleans, bigint, and decimal.

Comprehensive syntax: multi‑line data handling, conditional and loop statements, exception handling.

Functional programming features: Sequence abstraction, collection operations, and data transformation efficiency.

Extensibility: custom functions for complex business logic.

Aviator’s features make it ideal for our pre‑filter requirements, allowing flexible definition and management of complex filtering rules.

2) Protocol Conversion (Instruction Set)

When handling multiple event sources and delivery targets, message formats differ. To avoid hard‑coded conversions, we abstract a flexible protocol conversion process that maps source fields to target fields. The following diagram illustrates the conversion concept.

The required field transformations are listed in the table below:

source

operation

target

business_line

CHANGE

businesType

userid

CHANGE

uid

extra.resumeId

MOVE

resumeId

city

DELETE

-

We designed a custom instruction set:

CHANGE: rename a field.

MOVE: transfer a field, supporting nested structures.

DELETE: remove an unnecessary field.

ADD: add a fixed field for business identification.

Using this instruction set, we can flexibly define conversion rules without additional code. The following example shows a concrete conversion table.

source field

source value

command

target field

target value

business_line

58

CHANGE

businesType

58

city

beijing

DELETE

-

-

userid

10xxxxxxxx16

CHANGE

uid

10xxxxxxxx16

extra.resumeId

9x2

MOVE

resumeId

9x2

This standardized, configurable protocol conversion mechanism greatly enhances system flexibility and maintainability, forming a core part of the event‑driven service.

3.2 Business Process Abstraction and Reuse

We define a flow‑engine service that acts as the decision center of the execution chain, assembling various atomic capabilities. The engine uses a DAG (directed acyclic graph) to describe processes, which is then transformed into a tree structure for execution.

3.2.1 Atomic Capability Abstraction

Each node in the tree represents an atomic capability. Nodes are linked by rules that determine whether the next node should be triggered based on the current node’s result. The relationship is visualized as follows:

Each node contains a condition and the data required for execution. The execution result is stored in context and used as the condition for subsequent nodes.

3.2.2 Flow Engine Scheduling Mechanism

The flow engine is triggered by the event‑driven service. For each invitation rule, we abstract an invitation plan that defines the effective period of the process.

3.3 Business Component Layer Consolidation

Based on the atomic capabilities used by the flow engine, we abstract components such as audience segmentation, frequency control, A/B testing, effect regulation, recommendation matching, and content display. The flow engine can compose these components to define common business processes.

The architecture supports rapid onboarding of new business scenarios through configuration, eliminating the need for large‑scale code changes.

4. Effect Presentation

System Capability Consolidation All related businesses have completed the platform‑based architecture upgrade and continue to run and iterate on this architecture. Core capabilities such as audience segmentation, frequency control, A/B testing, effect regulation, recommendation matching, and content display are accumulated as public components, achieving personalized experiences for thousands of users.

Delivery Capability & Quality Platform‑based architecture and shared components significantly improve delivery quality, reduce code redundancy, and enhance system stability and reliability. Compared with other business architectures, the invitation system demonstrates strong parallel capability; most functionalities (effect control, recommendation matching, event triggers) are configuration‑driven, requiring minimal development. Action reuse exceeds 80% for new business onboarding.

5. Summary and Outlook

This article presented the platform‑based design and implementation thoughts for the invitation business, laying a solid foundation for future expansion and innovation. We are gradually introducing more AI capabilities, using large models to address matching intent, dialogue experience, and feedback throughout the recruitment process, thereby continuously improving the end‑to‑end hiring experience for both job seekers and employers.