austin: A Java Message Push Platform for Unified Multi-Channel Notification Delivery

What Problem austin Solves and Who It Is For

Enterprise applications commonly need to send messages through multiple channels: transactional SMS for order confirmations, email for reports, WeChat template messages for service accounts, DingTalk notifications for internal teams, and Android push for mobile users. Without a centralized platform, each product team implements its own integration for each channel, duplicating effort and creating inconsistent logging and monitoring.

austing addresses this by providing a single Java API for sending any supported message type. The README's stated design principle is that any company with internal messaging needs should have a platform like austin. The platform handles channel resource isolation, message lifecycle tracking, deduplication, frequency control, and night-time message blocking.

The primary audience is Java backend engineering teams at organizations with multiple product lines sending messages through several channels. It is not a hosted SaaS product; deploying austin requires managing a Java application server, MySQL, and Redis at minimum, with optional components for advanced features.

Supported Channels and Channel Isolation Design

The README documents ten message channels: SMS, email, WeChat service account template messages, WeChat mini program subscription messages, DingTalk group robot, DingTalk work messages, Android push notifications, enterprise WeChat robot messages, enterprise WeChat app messages, and Feishu robot messages.

A key design property is channel resource isolation. Each channel has its own processing queue, so a slow or failing SMS provider does not delay email delivery. The platform routes each message type through its own path end to end. This is architecturally different from a single-queue system where a backlog in one channel creates head-of-line blocking for all channels.

Channels that support rich media (DingTalk and enterprise WeChat rich text messages) require uploading assets to the channel platform first before the message can reference them. The README describes this as multi-channel asset management, handled through the platform's interface.

For SMS, the platform integrates with the hades rule engine, which allows adding a new SMS provider channel without a system restart or redeployment. Traffic between SMS providers can also be configured as a percentage split, so an organization can route 70% of SMS to one provider and 30% to another with a configuration change.

Deployment: Required and Optional Components

austin has two tiers of dependencies. The hard dependencies are MySQL and Redis, which together require approximately 2GB of memory. The Dockerfile at the repository root shows the deployment unit:

FROM openjdk:8-jre
ENV PARAMS="--spring.profiles.active=test"
WORKDIR /build
ADD ./austin-web/target/austin-web-0.0.1-SNAPSHOT.jar ./austin.jar
ENTRYPOINT ["sh","-c","java -jar $JAVA_OPTS austin.jar $PARAMS"]

The optional components are Kafka, Prometheus, Graylog, Flink, xxl-job, Apollo, and Hive. A full deployment of all services requires approximately 16GB of memory.

The docker-compose.yml starts the core infrastructure: austin-mysql (MySQL 5.7 on port 3306), austin-redis (Redis 3.2 on port 6379), austin-zookeeper (Zookeeper 3.8.4 on port 2181), austin-kafka (Kafka on port 9092), and a Flink job manager and task manager pair (port 8081). The kafka container is configured with three topics created automatically: austinBusiness, austinRecall, and austinTraceLog.

austing currently requires MySQL 5.7.x. If your environment uses MySQL 8.0, the README notes you must update the MySQL driver dependency in pom.xml and adjust the connection configuration accordingly.

Configuration and Initial Database Setup

The central configuration file is austin-web/src/main/resources/application.properties. Before starting the application, you must set spring.datasource with the MySQL ip, port, username, and password, and spring.redis with the Redis ip, port, and password. The application schema is in doc/sql/austin.sql, which must be executed against the database before first run.

The optional components each require additional configuration in the same file. Enabling scheduled tasks with xxl-job requires setting austin.xxl.job.ip and austin.xxl.job.port after deploying the xxl-job scheduling center. Enabling distributed log collection requires deploying Graylog and setting austin.graylog.ip. Enabling system monitoring requires deploying Prometheus and Grafana and configuring the Grafana dashboard.

For real-time data tracking via the data chain monitoring feature, the austin-stream module must be packaged as a JAR and submitted to a running Flink cluster. The JAR requires the Redis and Kafka connection settings embedded at com.java3y.austin.stream.constants.AustinFlinkConstant before packaging. The log topic name must exist in Kafka, set via austin.business.log.topic.name in application.properties.

The frontend admin system lives in a separate repository (ZhongFuCheng3y/austin-admin on GitHub) and must be deployed independently.

Message Lifecycle Tracking and Scheduling Features

The platform tracks each message through its full delivery lifecycle. Monitoring is available across three dimensions: by user, by template, and by message. The README describes this as near-real-time visibility into delivery status.

Message templates support placeholder variables, allowing a single template to be reused with different recipient-specific content passed at send time. Templates can be created and tested through the web management interface.

For bulk or scheduled message delivery, the platform supports uploading a CSV file containing a list of recipients combined with a cron expression to schedule timed dispatch. This is exposed through the template creation interface when the scheduled task option is selected.

Deduplication and frequency control are built in. The platform can filter out duplicate content sent to the same recipient within a configured window and can suppress messages during night hours, either blocking them outright or queuing them for next-day delivery. These controls reduce user fatigue and avoid violating channel-specific messaging rate limits.

Limitations and Where austin Is the Wrong Tool

austin is a Java 8 application (the Dockerfile uses openjdk:8-jre). Teams running modern Java versions (17+) will find the Dockerfile's base image outdated, though the pom.xml and application configuration can be adapted.

The last push to the repository was on 2026-06-10. The project is not archived. There are no GitHub releases, so there is no versioned release artifact; teams must build from source.

The full feature set (real-time data tracking, scheduled tasks, distributed logging, system monitoring, data warehouse) requires deploying and managing Flink, Kafka, xxl-job, Graylog, Prometheus, Grafana, and Hive. That is a substantial infrastructure footprint. Teams that only need simple multi-channel message dispatch without analytics might find the mandatory MySQL-plus-Redis minimum sufficient, but unlocking the tracking and scheduling capabilities requires investing in the optional stack.

austin is not appropriate as a drop-in library. It is a standalone platform with its own web management interface, API, and infrastructure requirements. Teams that need a library-level abstraction over a single channel (for example, a Java library for sending WeChat messages) should look at channel-specific SDKs instead.

The platform's documentation spans 107 documents totaling over 110,000 characters, hosted externally on Yuque. The in-repository documentation is limited to the README, the doc/sql/ directory, and the doc/INSTALL.md deployment guide. Teams without access to the Yuque documentation hub will find the in-repository documentation sparse for onboarding, particularly for configuring the optional Flink and Apollo components.

Editorial conclusion

austin suits Java development teams that need to centralize message delivery across SMS, email, WeChat, DingTalk, and push notifications under a single platform with deduplication, frequency control, and near-real-time tracking. The minimum deployment requires MySQL and Redis (about 2GB memory); the full stack with Flink, Kafka, and xxl-job requires approximately 16GB. Before deploying, verify you have MySQL 5.7.x configured in austin-web/src/main/resources/application.properties and that the austin.sql schema has been applied to your database.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. ZhongFuCheng3y/austin on GitHub