Designing Scalable Internet Architecture with Microservices, Message Queues, and Scheduled Tasks

Author: Zhu Ye, experienced in .NET and Java stacks, former MVP at Ubisoft, EF Education, 5173, Kongzhong, Ele.me, interested in technical management, system architecture, and deep learning.

Source: Technical Musings

The three "horses" of this architecture are micro‑services , message queues , and scheduled tasks . Together they form a three‑dimensional, extensible internet project structure that remains stable over long periods, regardless of project size.

Modules outlined with dashed boxes contain little business logic and act as thin wrappers that call services without touching databases. Black arrows indicate dependencies, while green and red arrows show the direction of MQ send and receive flows.

Micro‑services

Micro‑services are not new; the author has practiced this style for over a decade across four companies. The key is to design services around domain boundaries, which simplifies understanding, iteration, and reduces code duplication.

Benefits:

1. Clear product requirement discussion and domain division leads to well‑designed service data models, aligning technical and product architecture.

2. Precise service boundaries make it easy to locate where code changes are needed for new requirements.

3. Most business logic is reusable; new features often involve composing existing services.

4. Performance bottlenecks can be addressed by scaling individual services, reducing the scope of analysis.

5. When a business is deprecated, only the aggregate service needs to be taken offline; underlying common services remain untouched.

Service design principles:

1. Control service granularity, usually by domain first, then refine further.

2. Services are layered into three levels:

Aggregated Business Services: High‑level services that orchestrate complete business processes by invoking many basic services. They contain little data‑access logic.

Basic Business Services: Domain‑specific services that may call each other and handle core operations such as trading, user management, asset handling, etc.

Common Foundation Services: Independent services that provide generic capabilities (e.g., bank integration, digital signing, messaging) and are only called by the upper layers.

Each service should have its own database tables without cross‑references; data access must go through service APIs, ensuring encapsulation and easier refactoring, scaling, and fault isolation.

When services are called across machines or processes, considerations such as idempotency, compensation, timeout handling, and rate limiting become essential.

Although micro‑service adoption adds complexity, a well‑designed framework with monitoring and tracing mitigates operational pain.

Message Queue

Message queues bring several advantages:

1. Asynchronous processing – core order handling is fast, while downstream tasks (inventory, notifications) are processed later without blocking the user.

2. Traffic spikes – MQ acts as a buffer, allowing backend services to consume at a sustainable rate.

3. Module decoupling – events can be published once and consumed by many independent modules.

4. Broadcasting – multiple consumers can receive the same message without the producer needing to know the number of receivers.

Key implementation notes:

Prefer a dedicated listener project that only receives messages and forwards them to service APIs.

Critical messages should have a compensation path (e.g., a fallback job that pulls missed messages from the source service).

All message handling should be idempotent.

Support for delayed messages may be required depending on the MQ product.

Understand the two consumption models: single‑consumer (once‑only) and fan‑out (multiple consumers).

Monitor queue depth and set up alerts for backlog or storage issues.

Separate internal and external MQ clusters for security and performance isolation.

Scheduled Tasks

Scheduled jobs address three main needs:

1. Provide compensation for failed cross‑service or MQ notifications.

2. Drive business processes that are based on a task table stored in the database.

3. Execute periodic activities that do not require real‑time processing (e.g., sending expiration reminders, daily reconciliation, billing).

A typical task table includes fields such as ID, task type, external order number, status, retry count, processing history, timestamps, and optional business‑specific columns.

Job design principles:

Use a scheduling framework (ElasticJob, Quartz, etc.) in a separate project; avoid mixing job code with business services.

Jobs should contain only orchestration logic, delegating actual work to service APIs.

Compensation jobs must limit retry attempts to prevent dead‑letter blockage.

Finally, the article lists a comprehensive module breakdown (Site, Façade Service, Business Service, Foundation Service, Job) illustrating how each component can be packaged as an independent artifact, enabling flexible CI/CD pipelines.

Overall, the three‑horse architecture—micro‑services, message queues, and scheduled tasks—offers a scalable, maintainable solution for most internet projects, provided the team has sufficient experience with these patterns.