Unified Messaging Platform at a Large E-Commerce Platform
The unified messaging platform accepted notification requests from business systems, validated templates, resolved recipients, selected delivery channels, and sent messages through SMS, email, App Push, WeChat or Mini Programs, and in-app messaging. It also maintained a common record of delivery activity and results.
The platform was established in 2015 and continued to evolve through 2023. It brought previously separate messaging capabilities under common management, so order, membership, marketing, and operations systems did not need to integrate independently with multiple external providers.
Background
When every application integrates its own SMS, email, or push provider, interfaces and failure handling are repeatedly rebuilt. User identities such as phone numbers, email addresses, device identifiers, and OpenIDs are handled inconsistently. Changing a provider or adding a channel then requires coordinated changes across many applications.
The platform created a stable boundary between business systems and delivery channels. A caller described the recipient, template, and business parameters; the platform handled validation, account resolution, channel selection, delivery, and recording.
Role and key responsibilities
I was responsible for the messaging platform during its construction and evolution. The role covered architecture, interface standards, provider integration, production delivery, and operational governance. Key responsibilities included:
- designing consistent synchronous, asynchronous, and high-priority interfaces and defining the boundary with calling systems;
- establishing template groups, parameter validation, and configurable delivery methods;
- resolving a membership identity into the phone number, email address, device identifier, or OpenID required by each channel;
- separating SMS, email, App Push, social-platform, and in-app messaging capabilities from provider-specific SDKs and error models;
- bringing rate limits, blacklists, quiet hours, delivery records, receipts, inbound SMS, and billing ownership into platform governance;
- guiding the implementation from an early centralised system towards clearer Core, Service, API, and VIP modules with configuration, traffic control, metrics, and logging.
Beyond design, I stayed with the interface inventories, integration testing, production acceptance, provider changes, and the release governance that followed — from build through to daily operation.
Unifying multiple delivery channels
When an application submitted a notification, the platform first validated the template and parameters. It then resolved the membership identity into the account required by the selected channel and handed the request to the appropriate provider adapter.
This separated a stable business interface from frequently changing external services. A new SMS provider or App Push service could be introduced mainly within the platform, while calling applications continued to use the established contract.
The design did not pretend that every channel behaved identically. SMS required receipts, inbound messages, and unsubscribe records. In-app messages required partitioned storage for a large recipient population. App Push needed device and delivery-state management. The platform unified the calling process and governance while keeping genuine channel differences explicit.
Delivery governance and operational control
Messaging requires control over not only whether a notification is sent, but also its recipient, timing, frequency, and final result.
Rate and daily limits reduced repeated contact. Blacklists and unsubscribe records prevented delivery to excluded recipients. Requests received during quiet hours were stored for later processing, while delivery records, provider receipts, and status refresh jobs supported investigation and reconciliation.
These controls brought compliance, customer experience, provider cost, and operational stability under one set of platform rules rather than leaving each application to implement its own standard.
Continuing evolution and architecture judgement
The platform evolved from SMS, MMS, email, and WebService integration to proactive notifications, App Push, WeChat and Mini Programs, in-app messages, enhanced SMS, and virtual numbers. Providers, frameworks, and deployment environments changed, while templates, account resolution, and delivery records remained stable platform capabilities.
By 2023 a few things were still on my list: moving asynchronous delivery fully to durable tasks, unifying the result models that older interfaces each defined differently, and replacing the conditionals piled up in central orchestration with explicit channel strategies. Those belong to the next stage, and are worth keeping separate from what the platform already does.
Project value
The platform reduced direct dependencies between business applications and delivery providers. New channels, provider changes, delivery controls, and incident investigation could be handled centrally.
Business abstraction, interface and module design, multi-provider integration, operational controls, long-term evolution: the project handed me the whole architecture responsibility of carrying a platform from first release into continuing governance.