How to Build and Operate a Unified Java Message Push Platform with Austin

What is Austin?

Austin is a Java‑based unified message push platform. It provides a single HTTP entry point for sending notifications, abstracts the technical differences of various channels (Email, DingTalk, Enterprise WeChat, generic Webhook), and supports multi‑channel expansion and governance.

Core capabilities

Supports multiple channels such as Email, DingTalk, Enterprise WeChat, and Webhook.

Centralized message template management.

Zero‑intrusion HTTP API for business systems.

Traceable sending records.

Designed for microservice and mid‑platform architectures.

Environment preparation and deployment

Core dependencies

MySQL – stores templates, sending records, and configuration (recommended 5.7.x or 8.0).

Redis – cache and performance acceleration (any stable version).

⚠️ When using MySQL 8.0, ensure the JDBC driver and connection parameters are compatible.

Deployment options

Docker (strongly recommended)

docker-compose up -d

MySQL, Redis, and Austin start together.

Provides a consistent environment.

Low operational cost.

Manual deployment

# Build
mvn clean package

# Run
java -jar target/austin-web.jar

Prerequisite: MySQL and Redis are deployed and reachable.

Prerequisite: Application configuration is correct.

Configure message sending channels

🚨 This step determines whether Austin can actually send messages.

Common channel configuration examples

Email – SMTP address, port, and authorization code.

DingTalk – robot webhook URL.

Enterprise WeChat – corporate ID and application secret.

Webhook – target URL and authentication information.

Configuration procedure

Log into the Austin admin console.

Navigate to Channel Account Management .

Enter the key information obtained from the official platforms.

Austin centrally stores these configurations, so business systems do not need to be aware of them.

Create message templates

Templates must be created before sending. Example for DingTalk:

标题：${title}
内容：${content}

Standardizes content.

Supports dynamic parameter substitution.

Facilitates unified auditing and modification.

Send messages via HTTP API

After channel and template configuration, business systems only need to call Austin's HTTP API.

Call flow

Business system initiates an HTTP request.

Specify template ID, channel, and parameters.

Austin routes the request and sends the message.

Austin returns the sending result.

Example request

POST /api/v1/send HTTP/1.1
Host: your-austin-server:port
Content-Type: application/json

{
  "userId": "user123",
  "messageTemplateId": 1,
  "channel": "ding_ding_robot",
  "params": {
    "title": "系统通知",
    "content": "您的订单已处理完成。"
  }
}

messageTemplateId

: ID of the template created in the backend. channel: Identifier of the sending channel. params: Values for the template variables.

⚠️ Different Austin versions may have slight variations in API fields; refer to the actual documentation.

Common issues and troubleshooting

Message sending failure

Check Austin application logs.

Validate that channel keys are correct and not expired.

Confirm that the template matches the selected channel.

docker logs austin

Service cannot start

MySQL / Redis health.

Network reachability.

Database account permissions.

Correctness of application configuration.

Why not integrate SDKs directly?

Direct SDK integration leads to high code intrusion, costly channel changes, scattered templates, poor governance, and limited extensibility.

Problems with direct SDK integration

Code intrusion: Every business system must maintain its own sending logic.

Channel change cost: Switching from DingTalk to Enterprise WeChat requires code modifications across all services.

Template management: Message content is scattered in code, making unified updates difficult.

Governance: Lack of centralized audit, statistics, and rate‑limiting.

Extensibility: Adding a new channel forces changes in every consuming service.

Advantages of using Austin as a message middle‑platform

Unified HTTP API entry.

Centralized template management.

Channel switching without modifying business code.

Unified logging and failure tracing.

Complete decoupling of business logic from notification logic.

Architecture in microservice & Kubernetes environments

In cloud‑native setups, Austin typically runs as an independent service (Deployment or StatefulSet) exposed via ClusterIP or NodePort, with MySQL and Redis as backing services.

Recommended deployment diagram (ASCII)

┌─────────────┐
│ 业务系统 A   │
└─────┬───────┘
      │ HTTP
┌─────▼───────┐
│ 业务系统 B   │
└─────┬───────┘
      │
┌─────▼───────────────┐
│   Austin 消息中台   │
│ (Deployment / Pod) │
└─────┬───────────────┘
      │
┌─────▼─────┬─────▼─────┬─────▼─────┐
│   邮件    │   钉钉   │ 企业微信 │
└───────────┴───────────┴───────────┘

Role in Kubernetes

Austin: deployed as Deployment or StatefulSet, exposed via ClusterIP or NodePort.

MySQL / Redis: provided as cloud databases or in‑cluster services.

Business systems: only depend on Austin's API.

Architecture benefits

Standardized messaging capabilities.

Business systems can add new channels without code changes.

Non‑core capabilities are offloaded, keeping the main request path clean.

Real‑world scenarios

Scenario 1: Order status notification

Order placed → Email + DingTalk.

Shipment completed → Enterprise WeChat.

// Pseudo code
sendMessage(templateId, userId, params);

Scenario 2: System alarm

Service exception → DingTalk robot.

Critical failure → DingTalk + Enterprise WeChat.

Scenario 3: Approval flow notification

Pending approval → Enterprise WeChat.

Approval result → Email.

Key takeaways

Setup → Configure channels → Create templates → Call API

Typical use cases for Austin

Unified notification center for multiple business systems.

Message decoupling in microservice architectures.

Operations alerts, approval flows, and general business notifications.