About This Architecture

Campaign bulk messaging pipeline with dual prepaid and postpaid paths routes incoming client requests through Kafka topics, validation, and client-type determination before splitting into specialized processing streams. Ingestion via be-campaign API feeds kafka: bulk-topic, where be-campaign-validator enriches messages using Database and Redis Cache lookups, then routes to prepaid-low-bulk or postpaid queues based on client classification. Prepaid path consumes via be-prepaid-low, tracks usage through kafka: usage-cdr-low to prepaid-manager for balance reduction, then bulk-proc writes to prepaid databases and third-party APIs; postpaid path consumes directly to bulk-proc for content and status insertion. This architecture decouples ingestion from processing, enables independent scaling of prepaid and postpaid workloads, and ensures reliable message delivery across multiple sinks. Fork and customize this diagram on Diagrams.so to adapt topic names, add monitoring stages, or integrate additional validation rules.

People also ask

How do you design a scalable bulk messaging pipeline that handles both prepaid and postpaid customers with separate processing paths?

This diagram shows a Kafka-based pipeline where incoming messages are validated and enriched via be-campaign-validator using Database and Redis lookups, then routed to prepaid-low-bulk or postpaid queues based on client type. Each path has dedicated consumers (be-prepaid-low, bulk-proc) that write to separate databases and third-party APIs, enabling independent scaling and failure isolation.