CASE 02 / ENGINEERING IN DETAIL
Enterprise Customer Messaging Platform
Kafka accepts the requests, a rule chain validates them, and channel strategies handle dispatch.
Context and constraints
Business teams used IVR, SMS, push notifications, and automated calls to reach customers. Requests could arrive in bursts, while channels had different quotas and processing rates. I was responsible for platform architecture and core development, focusing on asynchronous requests, rule composition, and provider integration.
Core workflow
This diagram is a simplified view of the technical approach.
- 01 / Request intakeAsynchronous Kafka processing
- 02 / Business rulesFiltering, rate limits, and validation
- 03 / Channel strategyChannel and provider selection
- 04 / Delivery handlingProvider integration and exceptions
Design decisions and implementation
Buffer request bursts with Kafka
ChallengeRequests could arrive in bursts, while downstream channels had their own processing rates and integration limits.
ApproachUsed Kafka to process messaging requests asynchronously, separating request acceptance from downstream execution to buffer concentrated traffic.
ReasoningIntake and channel delivery can proceed at different rates. A queue only buffers that difference; backlog and provider quotas still need to be checked against consumption capacity.
Compose validation with a chain of responsibility
ChallengeCombining blocklists, traffic limits, phone-number resolution, and template requirements in one place would make rule changes difficult to manage.
ApproachLed development of a rule engine using a chain of responsibility for blocklist filtering, rate limiting, phone-number resolution, batch splitting, and template validation, composed for each business scenario.
ReasoningEach scenario can select the rules it needs. Changes to the chain still require checks for ordering and data dependencies between number resolution, batch splitting, and template validation.
Select providers within the channel layer
ChallengeChannels and SMS providers differed in carrier support, weights, quotas, and availability.
ApproachThe platform parses inputs by channel type and dispatches through channel strategies. SMS provider selection considers carrier, weight, and sending quota, with configured exception handling when no channel is available.
ReasoningBusiness callers submit requests by channel. Carrier matching, provider weights, and quota checks stay within the channel implementation.
What the design addresses
Implemented asynchronous Kafka processing, a chain-of-responsibility rule engine, and channel integrations, with SMS provider selection based on carrier, weight, and quota.
Validation focus
- Can queue backlog, consumption rate, and channel quotas be examined together after a request burst?
- Do filtering, batch splitting, and template validation retain their intended semantics when rules are recomposed?
- Do exhausted provider quotas and unavailable channels lead to explicit exception-handling paths?
My contribution
Responsible for platform architecture and core development. Led the rule engine, integrated third-party messaging services, and handled channel integration and push-delivery issues.