System and method for providing messaging services

Abstract

A system for providing scalable messaging services comprises a traffic management microservice, aggregation microservices, a resource management microservice, and a distribution microservice. The traffic management microservice receives and allocates message transmission requests from user equipments to aggregation microservices based on parameters such as workload, message priority, or network conditions. Each aggregation microservice extracts and verifies user and message information, determines whether transmission is authorized based on predefined rules, and validates each message against pre- approved templates. The distribution microservice transmits validated messages to destination devices through communication networks. The system may also include additional components, such as a provisioning microservice for managing subscriptions, a notification microservice for generating and transmitting notifications, and a network management microservice for performing FCAPS functions.

Description

SYSTEM AND METHOD FOR PROVIDING MESSAGING SERVICES RESERVATION OF RIGHTS

[0001] A portion of the disclosure of this patent document contains material, which is subject to intellectual property rights such as, but are not limited to, copyright, design, trademark, Integrated Circuit (IC) layout design, and / or trade dress protection, belonging to JIO PLATFORMS LIMITED or its affiliates (hereinafter referred as owner). The owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights whatsoever. All rights to such intellectual property are fully reserved by the owner.TECHNICAL FIELD

[0002] The present disclosure generally relates to the field of wireless communication systems. In particular, the present disclosure relates to a system and a method for providing messaging services in a distributed computing environment.DEFINITION

[0003] As used in the present disclosure, the following terms are generally intended to have the meaning as set forth below, except to the extent that the context in which they are used to indicate otherwise.

[0004] The expression “Messaging as a Service (MaaS) platform” used hereinafter in the specification refers to a platform designed to facilitate the end-to-end delivery, management, and aggregation of messaging services for enterprises. This platform offers a scalable, cloud-based solution that enables users to send and manage large volumes of messages across various channels, such as SMS, email, and multimedia messaging, to communicate effectively with their customers.

[0005] The expression “Enterprise provisioning gateway (EPG)” used hereinafter in the specification refers to a gateway that provisions or managesprepaid and postpaid subscriptions in the MaaS platform through a marketplace interface. The EPG enables the users to view and manage their subscriptions through the marketplace interface.

[0006] The expression “Aggregation microservice” used hereinafter in the specification refers to a microservice or component that facilitates the collection, management, and routing of messages (such as SMS) from the users to multiple customers. The aggregation microservice enables efficient bulk messaging by consolidating outgoing messages, verifying compliance with predefined templates, and ensuring delivery through approved channels.

[0007] The expression “Quota and Throttle Manager (QM)” used hereinafter in the specification refers to a component in the MaaS platform that is responsible for managing the usage limits and controlling the rate at which the messages are sent to the customer. The QM also tracks and verifies the available balance of messages that the users can send based on their subscription plan (prepaid or postpaid).

[0008] The expression “Notification Engine (NE)” used hereinafter in the specification refers to a component in the MaaS platform that is responsible for generating and managing notifications sent to users or enterprises regarding their purchased subscriptions.

[0009] The expression “Front-End Operations, Administration, and Maintenance (FEOAM)” used hereinafter in the specification refers to a component in the MaaS platform that performs a set of functionalities, such as overseeing the day-to-day operations of the messaging service, managing the delivery status, and similar. The FEOAM may include a user-friendly interface that allow users to easily interact with the system, access information, and perform necessary tasks without needing extensive technical knowledge. Further, the FEOAM provides administrative tools for managing user accounts, subscriptions, and access rights.

[0010] The expression "Load Balancer" used hereinafter in the specificationrefers to a component in the MaaS platform responsible for managing and distributing network and messaging traffic efficiently across multiple instances of the aggregation microservices.

[0011] The expression “Short Message Service (SMS)” refers to a mobile communication service that enables the exchange of short text messages, typically up to 160 characters, between mobile devices or between applications and mobile subscribers. SMS operates over cellular networks using standardized signaling channels, allowing reliable delivery of alerts, one time passwords (OTPs), promotional messages, and person-to-person communication even without an internet connection.

[0012] The expression “Short Message Service Center (SMSC)” refers to a network entity that is responsible for storing, forwarding, routing, and delivering SMS messages between mobile devices and external messaging platforms. It manages message queues, retries, delivery notifications, and ensures that SMS messages reach the intended subscriber even if the device is temporarily unavailable

[0013] The expression “Hypertext Transfer Protocol Secure (HTTPS) refers to a secure version of HTTP that encrypts data exchanged between a client and server. HTTPS ensures the confidentiality, integrity, and authenticity of application programming interface (API) calls used in messaging services.

[0014] The expression “Short Message Peer-to-Peer (SMPP) refers to a protocol used to exchange short message service (SMS) messages between messaging platforms and SMSCs. The SMPP supports high-throughput, low-latency SMS delivery commonly used for OTPs, alerts, and bulk messaging.

[0015] The expression “Message Queuing Telemetry Transport (MQTT)” refers to a lightweight publish-subscribe messaging protocol designed for low-bandwidth, high-latency, or loT environments. MQTT enables real-time in-app communication and device notifications.

[0016] The expression “WebSocket” refers to a full-duplex communication protocol that allows persistent, real-time, bidirectional data exchange between a client and a server. WebSocket is widely used for chat systems, live notifications, and interactive messaging.

[0017] The expression “Simple Mail Transfer Protocol (SMTP)” refers to a standard protocol for sending and routing email messages across mail servers. Messaging systems use SMTP to deliver transactional, promotional, or automated email notifications.

[0018] These definitions are in addition to those expressed in the art.BACKGROUND

[0019] The following description of related art is intended to provide background information pertaining to the field of the disclosure. This section may include certain aspects of the art that may be related to various features of the present disclosure. However, it should be appreciated that this section be used only to enhance the understanding of the reader with respect to the present disclosure, and not as admissions of prior art.

[0020] Nowadays, enterprises communicate more with their customers via mobile messaging to deliver time-sensitive alerts, customer services, order updates etc. Additionally, mobile messaging is increasingly used as a key channel for most brands and enterprises to promote and market their products and services to attract and engage new customers.

[0021] Most enterprises use messaging aggregators (also referred to as messaging aggregation microservices) to reach their customers. A messaging aggregator is a platform that connects businesses and mobile network operators. Its primary function is to facilitate the large-scale delivery of business messages, such as promotional offers, transactional alerts, and customer service communications, across multiple networks and geographic regions. Additionally, messagingaggregators act between businesses and mobile network operators, ensuring each message is routed correctly to the intended customer or recipients.

[0022] Currently, mobile network operators provide the essential infrastructure for these messaging services while the messaging aggregators handle the complexity of integrating with various enterprises and distributing messages. While messaging aggregators offer enterprises a powerful and efficient way of reaching their customers, they capture a significant portion of the revenue generated from the messaging services. The mobile network operators often receive a small portion of the revenue. This limited involvement of mobile network operators results in a significant loss of potential earnings in their business. Furthermore, mobile network operators often have limited options to influence pricing models, offer tailored services, or capture a significant revenue share.

[0023] There is, therefore, a need in the art to provide a method and a system that can mitigate the disadvantages of the prior art.SUMMARY OF THE DISCLOSURE

[0024] In an exemplary embodiment, a method for providing messaging services in a distributed computing environment is described. The method includes receiving, by atraffic management microservice, one or more message transmission requests from one or more user equipment (UEs). The method includes allocating, by the traffic management microservice, on or more message transmission requests across a plurality of aggregation microservices based on one or more parameters. The method includes extracting and verifying, by each aggregation microservice, user and message information associated with the message transmission requests using data obtained from a provisioning microservices. The method includes upon verification, determining by a resource management microservice, whether the transmission of a message is authorized based on one or more predefined rules. The method includes performing, by each aggregation microservice, validation of each message based on one or more parameters. The method includes transmitting, by a distribution microservice, the validated message to one or more destination devicesthrough one or more communication networks.

[0025] In some embodiments, each microservice is configured to operate as an independent and containerized service communicating through one or more application programming interfaces (APIs). The one or more parameters comprise, but not limited to, workload, message priority, or network conditions. The one or more predefined rules comprise, but not limited to, at least one of balance availability and compatibility check. The messaging services comprise, but not limited to, at least one of short messaging service (SMS), electronic mail (email), multimedia message (MMS), rich communication service message (RCS), an instant message, promotional messages, transactional messages, and service messages.

[0026] In some embodiments, the method includes the step of verifying the extracted information of a user comprises accessing, by each aggregation microservice, subscription details corresponding to the user from a database and the subscription details comprise one or more of a subscription level, a service duration, subscription credentials, a subscription type and a subscription status. The method includes matching, by each aggregation microservice, the accessed subscription details with the extracted information of the user to determine whether the subscription status is an active status or an inactive status and upon determining the subscription status is the active status, exchanging, by each aggregation microservice, the extracted information with the resource management microservice for authorization.

[0027] In some embodiments, the step of the compatibility check comprises accessing, by each aggregation microservice, one or more pre-approved messaging templates from the database. The method includes comparing, by each aggregation microservice, each of the one or more message transmission requests with the one or more accessed pre-approved messaging templates. The method includes upon detecting each of the one or more message transmission requests matches with the one or more accessed pre-approved messaging templates, marking, by eachaggregation microservice, a corresponding message transmission request as a compatible request and upon detecting each of the one or more message transmission requests that do not match with the one or more accessed pre-approved messaging templates, rejecting, by each aggregation microservice, the transfer of the message, the message comprises at least one of promotional messages, transactional messages, and service messages.

[0028] In some embodiments, the method includes generating and transmitting, by a notification microservice, one or more notifications associated with at least one subscription activity, system alerts, quota usage to the user or an enterprise system.

[0029] In some embodiments, the method includes performing, by a network management microservice, one or more functions corresponding to fault, configuration, accounting, performance and security (FCAPS) and the one or more functions comprise monitoring system faults, maintaining configuration logs, recording messaging accounting data, evaluating performance metrics and enforcing security policies across the distributed computing environment.

[0030] In some embodiments, the method includes managing, by the provisioning microservice, one or more subscription management operations and the one or more subscription management operations comprise at least one of activation, deactivation, and modification of subscriptions, and the traffic management microservice is configured to apply a machine learning model to perform one or more traffic management operations. The one or more traffic management operations comprise at least one of message traffic prediction, message routing and resource allocation.

[0031] In another exemplary embodiment, a system for providing scalable messaging services in a distributed computing environment is disclosed. The system includes a traffic management microservice configured to receive one or more message transmission requests from one or more user devices. The system includes the traffic management microservice configured to allocate the one ormore message transmission requests across a plurality of aggregation microservices based on one or more parameters and each aggregation microservice configured to extract and verify user and message information associated with the message transmission requests using data obtained from a provisioning microservice. The system includes upon verification, a resource management microservice configured to determine whether transmission of a message is authorized based on one or more predefined rules. Each aggregation microservice configured to perform validation of each message based on one or more pre-approved templates and a distribution microservice configured to transmit the validated message to one or more destination devices through one or more communication networks.

[0032] In yet another exemplary embodiment, a user equipment (UE) communicatively coupled with a system, the coupling comprises steps of: receiving, by the system, a connection request from the UE. Sending, by the system, an acknowledgment of the connection request to the UE and transmitting, by the UE, at least one request to send one or more message transmission requests to the system and the system is configured to provide scalable messaging services in a distributed computing environment. The system includes a traffic management microservice configured to receive one or more message transmission requests from one or more user devices. The system includes the traffic management microservice configured to allocate the one or more message transmission requests across a plurality of aggregation microservices based on one or more parameters and each aggregation microservice configured to extract and verify user and message information associated with the message transmission requests using data obtained from a provisioning microservice. The system includes upon verification, a resource management microservice configured to determine whether transmission of a message is authorized based on one or more predefined rules. Each aggregation microservice configured to perform validation of each message based on one or more pre-approved templates. A distribution microservice configured to transmit the validated message to one or more destination devices through one or more communication networks.

[0033] In yet another exemplary embodiment, a computer program product comprising a non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform a method for providing scalable messaging services in a distributed computing environment is disclosed. The method includes receiving, by a traffic management microservice, one or more message transmission requests from one or more user equipments (UEs) and allocating, by the traffic management microservice, the one or more message transmission requests across a plurality of aggregation microservices based on one or more parameters. The method includes extracting and verifying, by each aggregation microservice, user and message information associated with the message transmission requests using data obtained from a provisioning microservice. The method includes upon verification, determining, by a resource management microservice, whether transmission of a message is authorized based on one or more predefined rules, performing, by each aggregation microservice, validation of each message based on one or more regulatory and organizational policies and transmitting, by a distribution microservice, the validated message to one or more destination devices through one or more communication networks.OBJECTIVE OF THE PRESENT DISCLOSURE

[0034] Some of the objectives of the present disclosure, which at least one embodiment herein satisfies, are as follows:

[0035] An objective of the present disclosure is to provide a system and a method for providing messaging services in a distributed computing environment.

[0036] An objective of the present disclosure is to provide a messaging platform that functions as an aggregation microservice, offering aggregation and short message service (SMS) delivery services to users, such as enterprises or retail customers.

[0037] Another objective of the present disclosure is to offer differentmicroservices designed as a microservice architecture to offer messaging solutions and manage enterprise subscriptions.

[0038] Yet another objective of the present disclosure is to disrupt the traditional messaging aggregation microservice model by offering the MaaS architecture platform that manages both message accumulation and delivery.

[0039] Yet another objective of the present disclosure is to provide a cloudnative platform that facilitates multiple connectivity and interface options for enterprises.

[0040] Yet another objective of the present disclosure is to send messages (e.g., SMS / Email) based notifications associated with subscription activities, system alerts or even quota messages to the user or enterprise system, thereby protecting cross-channel notification mechanisms, expanding coverage beyond SMS-only to email, app push, or voice messages.

[0041] Yet another objective of the present disclosure is to perform FCAPS functions, including monitoring system faults, maintaining configuration logs, recording message accounting data, evaluating performance metrics, and enforcing security policies across the microservice, thereby providing protection for networkgrade management and analytics.

[0042] Yet another objective of the present disclosure is to manage enterprise subscriptions, including activation, deactivation, and modification of prepaid and postpaid accounts via a self-service portal, thereby tying the messaging platform directly to subscription lifecycle management.

[0043] Yet another objective of the present disclosure is to employ a machine learning model to predict message traffic surges and dynamically optimize routing and resource allocation, thereby anticipating scalability improvements and protecting intelligent load management systems.

[0044] Other objectives and advantages of the present disclosure will be moreapparent from the following description, which is not intended to limit the scope of the present disclosure.BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS

[0045] The accompanying drawings, which are incorporated herein, and constitute a part of this disclosure, illustrate exemplary embodiments of the disclosed methods and systems in which like reference numerals refer to the same parts throughout the different drawings. Components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. Some drawings may indicate the components using block diagrams and may not represent the internal circuitry of each component. It will be appreciated by those skilled in the art that disclosure of such drawings includes the disclosure of electrical components, electronic components or circuitry commonly used to implement such components.

[0046] FIG. 1 illustrates an exemplary network architecture of a system configured for providing messaging services in a distributed computing environment, in accordance with an embodiment of the present disclosure.

[0047] FIG. 2 illustrates an exemplary block diagram of the system, in accordance with an embodiment of the present disclosure.

[0048] FIG. 3 illustrates an exemplary system architecture configured for providing messaging services, in accordance with an embodiment of the present disclosure.

[0049] FIG. 4 illustrates an exemplary process workflow for providing messaging services, in accordance with an embodiment of the present disclosure.

[0050] FIG. 5 illustrates an exemplary flow diagram of a method for providing messaging services in the distributed computing environment, in accordance with an embodiment of the present disclosure.

[0051] FIG. 6 illustrates an exemplary computer system in which or with which the embodiments of the present disclosure may be implemented.

[0052] The foregoing shall be more apparent from the following more detailed description of the disclosure.LIST OF REFERENCE NUMERALS100 - Network Architecture102 - User(s)104 -User Equipments (UEs)106 - Network108 - System200 - Block diagram202 - Processor(s)204 - Memory206 -Interface(s)208 - Traffic management Microservice210 - Provisioning Microservice212 - Notification Microservice214 - Resource Management Microservice216 - Aggregation Microservice(s)218 - Distribution Microservice219 - Network Management Microservice 300 - System Architecture302 - Marketplace Interface304 - Enterprise Provisioning Gateway (EPG) 306 - Frond End (FE)308 - Network Management System (NMS) 310 - Command Line Interface (CLI)312 - Load Balancer314 - Quota and Throttle Manager (QM) 316 - Notification Engine (NE)318 - Distributed ledger technology (DLT) 320 - Short Message Service Center (SMSC) 322 - Mail Server400 - Flow Diagram500 - Flow Diagram600 - Computer System610 - External Storage Device620 - Bus630 - Main Memory640 - Read Only Memory650 - Mass Storage Device660 - Communication Port670 - ProcessorDETAILED DESCRIPTION

[0053] In the following description, for the purposes of explanation, various specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can each be used independently of one another or with any combination of other features. An individual feature may not address any of the problems discussed above or might address only some of the problems discussed above. Some of the problems discussed above might not be fully addressed by any of the features described herein. Example embodiments of the present disclosure are described below, as illustrated in various drawings in which like reference numerals refer to the same parts throughout the different drawings.

[0054] The ensuing description provides exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing an exemplary embodiment. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the disclosure as set forth.

[0055] Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and othercomponents may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.

[0056] Also, it is noted that individual embodiments may be described as a process that is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function.

[0057] The word “exemplary” and / or “demonstrative” is used herein to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited by such examples. In addition, any aspect or design described herein as “exemplary” and / or “demonstrative” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques known to those of ordinary skill in the art. Furthermore, to the extent that the terms “includes,” “has,” “contains,” and other similar words are used in either the detailed description or the claims, such terms are intended to be inclusive like the term “comprising” as an open transition word without precluding any additional or other elements.

[0058] Reference throughout this specification to “one embodiment” or “an embodiment” or “an instance” or “one instance” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, the appearances of thephrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0059] The terminology used herein is to describe particular embodiments only and is not intended to be limiting the disclosure. As used herein, the singular forms “a”, “an”, and “the” are intended to include the plural forms as well, unless the context indicates otherwise . It will be further understood that the terms “comprises” and / or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. As used herein, the term “and / or” includes any combinations of one or more of the associated listed items. It should be noted that the terms “mobile device”, “user equipment”, “user device”, “communication device”, “device” and similar terms are used interchangeably for the purpose of describing the invention. These terms are not intended to limit the scope of the invention or imply any specific functionality or limitations on the described embodiments. The use of these terms is solely for convenience and clarity of description. The invention is not limited to any particular type of device or equipment, and it should be understood that other equivalent terms or variations thereof may be used interchangeably without departing from the scope of the invention as defined herein.

[0060] As used herein, an “electronic device”, or “portable electronic device”, or “user device” or “communication device” or “user equipment” or “device” refers to any electrical, electronic, electromechanical, and computing device. The user device is capable of receiving and / or transmitting one or parameters, performing function / s, communicating with other user devices, and transmitting data to the other user devices. The user equipment may have a processor, a display, a memory, a battery, and an input-means such as a hard keypad and / or a soft keypad. The user equipment may be capable of operating on any radio access technology includingbut not limited to IP-enabled communication, Zig Bee, Bluetooth, Bluetooth Low Energy, Near Field Communication, Z-Wave, Wi-Fi, Wi-Fi direct, etc. For instance, the user equipment may include, but not limited to, a mobile phone, smartphone, virtual reality (VR) devices, augmented reality (AR) devices, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other device as may be obvious to a person skilled in the art for implementation of the features of the present disclosure.

[0061] Further, the user device may also comprise a “processor” or “processing unit” includes processing unit, wherein processor refers to any logic circuitry for processing instructions. The processor may be a general-purpose processor, a special purpose processor, a conventional processor, a digital signal processor, a plurality of microprocessors, one or more microprocessors in association with a Digital Signalling Processing (DSP) core, a controller, a microcontroller, Application Specific Integrated Circuits, Field Programmable Gate Array circuits, any other type of integrated circuits, etc. The processor may perform signal coding data processing, input / output processing, and / or any other functionality that enables the working of the system according to the present disclosure. More specifically, the processor is a hardware processor.

[0062] While considerable emphasis has been placed herein on the components and component parts of the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiment, as well as other embodiments of the disclosure, will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be interpreted merely as illustrative of the disclosure and not as a limitation.

[0063] Nowadays, most enterprises use messaging aggregators to reach their customers. A messaging aggregator is a platform that connects businesses and mobile network operators. Its primary function is to facilitate the large-scaledelivery of business messages, such as promotional offers, transactional alerts, and customer service communications, across multiple networks and geographic regions. Additionally, messaging aggregators act between businesses and mobile network operators, ensuring messages are routed correctly to the intended customers or recipients.

[0064] At present, mobile network operators provide the essential infrastructure for bulk messaging services while messaging aggregators handle the complexity of integrating with various enterprises and distributing messages. While messaging aggregators offer enterprises a powerful and efficient way of reaching their customers, they capture a significant portion of the revenue generated from the messaging services. Thus, the mobile network operators often receive a small portion of the revenue. This limited involvement of mobile network operators results in a significant loss of potential earnings in their businesses. Further, an additional layer introduced by the aggregators can increase message delivery times, leading to delays in communication that may negatively affect customer satisfaction and business operations.

[0065] Hence, there is a need to provide a system and a method that can address the shortcomings of existing solutions.

[0066] The present disclosure provides a messaging as a service (MaaS) platform divided into a plurality of sub microservices or components and designed as a microservice architecture. The microservice architecture makes the MaaS platform highly scalable and reliable in providing messaging solutions. The MaaS platform also manages users’ subscriptions.

[0067] Further, the MaaS platform enables direct integration between enterprise and mobile network operators, eliminating the need for messaging aggregators. This allows the mobile network operators to maintain greater control over pricing, service offerings, and revenue sharing, ultimately leading to increased profitability. Furthermore, the MaaS platform provides detailed insights into messaging traffic, performance metrics, and revenue generation. This transparencyfurther enables mobile network operators to make informed decisions and optimize their services effectively.

[0068] Hereinafter, exemplary embodiments of the present disclosure will be described with reference to the accompanying drawings.

[0069] The various embodiments throughout the disclosure will be explained in more detail with reference to FIGS. 1- 6.

[0070] FIG. 1 illustrates an exemplary network architecture 100 of a system 108 configured for providing messaging services, in accordance with an embodiment of the present disclosure.

[0071] As illustrated in FIG. 1, the network architecture 100 may include one or more User Equipments (UEs) 104-1, 104-2... 104-N associated with one or more users (interchangeably referred to as an enterprise or enterprise users or system users or retail users) 102-1, 102-2... 102-N in an environment. A person of ordinary skill in the art will understand that one or more users 102-1, 102-2... 102-N may be collectively referred to as the user 102. In an embodiment, the user 102 can be an enterprise itself. In another embodiment, the user 102 can be any authorized person or administrator from the enterprise who is responsible for the delivery of bulk messages to consumers of the enterprise. In yet another embodiment, the user 102 can be an ordinary user willing to send bulk messages. Similarly, a person of ordinary skill in the art will understand that one or more UEs 104-1, 104-2... 104-N may be collectively referred to as the UE 104 or the UEs 104. For example, the user 102 may be associated with the UE 104. Although only three UEs 104 are depicted in FIG. 1, any number of the UE 104 may be included without departing from the scope of the ongoing description.

[0072] In an aspect, the enterprise refers to a business entity, organization, or service provider that uses the messaging services to send, manage, and monitor large-scale communication activities, for example, short message service (SMS), email, rich communication services (RCS), WhatsApp, or push notifications, tocustomers, users, or internal stakeholders. In the distributed computing environment, the enterprise interacts with the system through application programming interfaces (APIs), dashboards, or automated workflows to perform operations, for example, submitting messages, managing subscriptions, configuring templates, monitoring delivery analytics, and enforcing compliance. The enterprise acts as the originating client of the messaging services, relying on the distributed computing environment’s microservices (e.g., traffic management microservice, provisioning microservice, aggregation microservices, distribution microservice, and notification microservices) to guarantee high availability, scalability, and reliable delivery of communication across multiple communication channels.

[0073] In an embodiment, the UE 104 may include smart devices operating in a smart environment, for example, an Internet of Things (loT) system. In such an embodiment, the UE 104 may include, but are not limited to, smartphones, smart watches, smart sensors (e.g., a mechanical, a thermal, an electrical, a magnetic, etc.), networked appliances, networked peripheral devices, networked lighting system, communication devices, networked vehicle accessories, networked vehicular devices, smart accessories, tablets, a smart television (TV), computers, a smart security system, a smart home system, other devices for monitoring or interacting with or for the user 102 and / or entities, or any combination thereof. A person of ordinary skill in the art will appreciate that the UE 104 may include, but not limited to, intelligent, multi-sensing, network-connected devices, that may integrate seamlessly with each other and / or with a central server or a cloudcomputing system or any other device that is network-connected.

[0074] Additionally, in some embodiments, the UE 104 may include, but not limited to, a handheld wireless communication device (e.g., a mobile phone, a smartphone, a phablet device, and so on), awearable computer device (e.g., aheadmounted display computer device, a head-mounted camera device, a wristwatch computer device, and so on), a Global Positioning System (GPS) device, a laptop computer, a tablet computer, or another type of portable computer, a media playing device, a portable gaming system, and / or any other type of computer device withwireless communication capabilities, and the like. In an embodiment, the UE 104 may include, but are not limited to, any electrical, electronic, electromechanical, or equipment, or a combination of one or more of the above devices, such as virtual reality (VR) devices, augmented reality (AR) devices, a laptop, a general-purpose computer, a desktop, a personal digital assistant, a tablet computer, a mainframe computer, or any other computing device. Further, the UE 104 may include one or more in-built or externally coupled accessories including, but not limited to, a visual aid device such as a camera, an audio aid, a microphone, a keyboard, and input devices for receiving input from the user 102 or an entity such as a touchpad, a touch-enabled screen, an electronic pen, and the like. A person of ordinary skill in the art will appreciate that the UE 104 may not be restricted to the mentioned devices and various other devices may be used.

[0075] In FIG. 1, the UE 104 may communicate with the system 108 through a network 106 (e.g., a Radio Access Network (RAN) for sending or receiving various types of data, such as a registration request for registering with the system 108, a message delivery initiation request for initiating messages delivery process, a response of delivery of one or more short message service (SMS) and the like. In an embodiment, for using the system 108, the user 102 may need to register themselves with the system 108. Once the user 102 is registered with the system 108, the user 102 can initiate the messaging delivery process using the system 108. In an embodiment, the messaging delivery process can be initiated by composing one or more SMS using a messaging application on their UE 104. The system 108 then processes the one or more SMS, and after processing, the system 108 may send a response back to the UE 104 through the network 106 to confirm the status of the one or more SMS (e.g., successful submission, failure due to insufficient balance, etc.).

[0076] In an embodiment, the network 106 may include at least one of a Fifth Generation (5G) network, a Sixth Generation (6G) network, or the like. The network 106 may enable the UE 104 to communicate with other devices in the network architecture 100 and / or with the system 108. The network 106 may includea wireless card or some other transceiver connection to facilitate this communication. In another embodiment, the network 106 may be implemented as, or include any of a variety of different communication technologies such as a wide area network (WAN), a local area network (LAN), a wireless network, a mobile network, a Virtual Private Network (VPN), an Internet, the Public Switched Telephone Network (PSTN), or the like.

[0077] In an embodiment, the network 106 may include, by way of example but not limitation, at least a portion of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, waves, voltage or current levels, some combination thereof, or so forth. The network 106 may also include, by way of example but not limitation, one or more of the RAN, a wireless network, a wired network, an internet, an intranet, a public network, a private network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a Public-Switched Telephone Network (PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, or some combination thereof.

[0078] In an embodiment, the UE 104 is communicatively coupled with the network (RAN) 106. The network 106 may receive a connection request from the UE 104. The network 106 may send an acknowledgment of the connection request to the UE 104. The UE 104 may transmit a plurality of signals in response to the connection request. Once the connection is successfully established, the user 102 can send a request to initiate the message delivery process to send one or more SMSs to the intended customers / recipients. Upon receiving the request, the system 108 is configured to perform the message delivery process for delivering the one or more received SMSs to the desired customers. The system 108 may also send a response about the delivery of the one or more SMS to the UE 104.

[0079] Although FIG. 1 shows exemplary components of the network architecture 100, in other embodiments, the network architecture 100 may includefewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 1. Additionally, or alternatively, one or more components of the network architecture 100 may perform functions described as being performed by one or more other components of the network architecture 100.

[0080] FIG. 2 illustrates an exemplary block diagram 200 of the system 108 configured for providing messaging services, in accordance with an embodiment of the disclosure. FIG. 2 is explained in conjunction with FIG. 1.

[0081] In an embodiment, the system 108 may include one or more processor(s) 202. The one or more processor(s) 202 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, logic circuitries, and / or any devices that process data based on operational instructions. Among other capabilities, the one or more processor(s) 202 may be configured to fetch and execute computer-readable instructions stored in a memory 204 of the system 108. The memory 204 may be configured to store one or more computer-readable instructions or routines in a non-transitory computer readable storage medium, which may be fetched and executed to create or share data packets over a network service. The memory 204 may include any non-transitory storage device including, for example, volatile memory such as a Random-Access Memory (RAM), or a non-volatile memory such as an Erasable Programmable Read Only Memory (EPROM), a flash memory, and the like.

[0082] In an embodiment, the system 108 may include an interface(s) 206. The interface(s) 206 may include a variety of interfaces, for example, interfaces for data input and output devices (RO), storage devices, and the like. The interface(s) 206 may facilitate communication through the system 108. The interface(s) 206 may also provide a communication pathway for one or more components of the system 108.

[0083] In an embodiment, the system 108 may include a traffic management microservice 208, a provisioning microservice 210, a notification microservice 212,a resource management microservice 214, a plurality of aggregation microservices 216, a distribution microservice 218 and a network management microservice 219.

[0084] In an aspect, the traffic management microservice 208 refers to a microservice that dynamically analyzes incoming message requests and distributes them across available microservices based on workload, priority, and network conditions. The traffic management microservice 208 ensures optimal routing, prevents congestion, and maintains system-wide delivery efficiency.

[0085] In an aspect, the provisioning microservice 210 refers to a microservice that manages the registration, configuration, and lifecycle settings of enterprise accounts, sender IDs, templates, and messaging rules. The provisioning microservice 210 ensures that all required resources and compliance parameters are correctly provisioned before message processing begins.

[0086] In an aspect, the notification microservice 212 refers to a microservice that system-level alerts, status updates, acknowledgments, and error notifications for internal components and external users. The notification microservice 212 provides real-time communication regarding delivery status, failures, or system events.

[0087] In an aspect, the resource management microservice 214 refers to a microservice that oversees the allocation, monitoring, and optimization of compute, storage, and network resources across the distributed computing environment. The resource management microservice 214 maintains service health and ensures resources scale according to traffic demands.

[0088] In an aspect, each aggregation microservice 216 of the plurality of aggregation microservices 216 refers to a microservice that collects and processes message transmission requests, extracts user and message metadata, and prepares payloads for protocol-specific delivery. The plurality of aggregation microservices 216 operates in parallel to support high throughput and handle distributed loads.

[0089] In an aspect, the distribution microservice 218 refers to a microservice that delivers processed messages to downstream gateways or channel providers (e.g., SMSC, email SMTP servers, OTT APIs) using the appropriate communication protocol. The distribution microservice 218 ensures protocol-compliant delivery and handles retries, fallbacks, and delivery optimizations.

[0090] In an aspect, the network management microservice 219 refers to a microservice that monitors and manages connectivity, bandwidth, routing paths, and network-level QoS parameters across communication channels. The network management microservice 219 detects network disruptions, optimizes channel selection, and ensures reliable end-to-end message transmission.

[0091] In an embodiment, the system 108 is configured to provide messaging services to their users. The messaging services may include functionalities such as sending, receiving, and managing messages, including, but not limited to, text messages, multimedia messages, and notifications, across various communication channels. In an operative aspect, the system 108 is configured to provide scalable messaging services in the distributed computing environment. The distributed computing environment refers to an architecture in which messaging functions, such as validation, routing, channel adaptation, queuing, and delivery, are executed across multiple independent and interconnected microservices, rather than a single centralized system. For example, the messaging services are provided in the distributed computing environment through the microservices, i.e., the traffic management microservice 208, the provisioning microservice 210, the notification microservice 212, the resource management microservice 214, the plurality of aggregation microservices 216, the distribution microservice 218 and the network management microservice.

[0092] The scalable messaging service is provided within the distributed computing environment to facilitate reliable and high-throughput message exchange among the user equipment (UE) by using microservices. The scalable messaging service is configured to dynamically manage message generation,routing, and delivery based on system load and network conditions. The messaging service employs a distributed architecture comprising multiple interconnected microservices. The messages are partitioned, replicated, and balanced across the microservices to ensure continuous availability and fault tolerance. In an aspect, the scalable messaging service may employ one or more scalability mechanisms. The scalability mechanisms may comprise, but are not limited to, load balancing, auto scaling, and elastic resource allocation.

[0093] In the load balancing, incoming message transmission requests are distributed evenly across multiple microservice instances to prevent any single component from becoming overloaded. In a distributed messaging environment, the load balancer continuously monitors the health, capacity, and workload of microservices (e.g., SMS, email, push, or OTT) and directs each new request to the instance that processes it most efficiently. This distribution ensures high throughput, reduces processing latency, and prevents system failures caused by uneven load concentration. For example, when the system receives 20,000 SMS requests per minute during a bank’s peak OTP hours, the load balancer divides these requests across several SMPP gateway microservice instances, sending 5,000 messages to each of four instances instead of overwhelming one. As a result, traffic remains smooth, messages are delivered quickly, and the platform easily scales by adding more instances if the load increases further.

[0094] In the auto scaling, the number of microservice instances is automatically increased or decreased based on resource utilization metrics, for example, CPU load, memory consumption, message queue depth, or predicted traffic surges. When traffic increases, new instances are rapidly instantiated; when traffic decreases, idle instances are safely terminated, ensuring cost-efficiency. This elasticity enables the messaging platform to handle sudden peaks, for example, time-bound alerts or marketing campaigns, without manual intervention while maintaining consistent performance and SLA compliance.

[0095] In the elastic resource allocation, resource pools (e.g., computation,storage, network bandwidth) are dynamically expanded or contracted by, but are not limited to, container orchestration platforms, distributed service controllers, and virtual machine auto-scalers.

[0096] The scalable service enables messaging services without service interruption, thereby maintaining consistent performance under varying traffic demands. Through asynchronous communication and message persistence mechanisms, the scalable messaging service decouples producers and consumers, mitigates network latency, and ensures reliable message delivery. The scalable messaging services in the distributed computing environment enhance system elasticity, throughput, and resilience, enabling efficient coordination and data synchronization across distributed applications or microservices.

[0097] In an aspect, the messaging services comprise, but are not limited to, at least one of short messaging service (SMS), electronic mail (Email), multimedia message (MMS), rich communication service message (RCS), an instant message, promotional messages, transactional messages, and service messages. In an aspect, the SMS refers to a text-based communication service that allows sending short alphanumeric messages over the network. In an aspect, the Email refers to a digital message service for sending text, files, or multimedia content over the network between email addresses. In an aspect, the MMS refers to an extension of SMS that supports sending images, audio, video and text messages over the network. In an aspect, the RCS refers to an advanced messaging protocol that enables real-time chat features, for example, file sharing, read receipts, and group messaging. The RCS enables real-time chat features by providing an internet protocol (IP)-based messaging protocol that extends traditional SMS with capabilities similar to instant messaging applications. For example, a user interacting with a banking service via RCS may receive a real-time confirmation of a fund transfer, see typing indicators from customer support, and exchange multimedia messages, all within the same conversation thread. The system supporting RCS ensures message synchronization, delivery acknowledgment, and presence information, providing a seamless, interactive, and responsive chat experience comparable to the messagingapplications. In an aspect, the instant message refers to real-time text-based communication between users via internet-based applications or platforms, often supporting emojis, media, and voice / video chat. In an aspect, the promotional messages refer to marketing-oriented messages sent to advertise products, offers, or services to a large audience, usually with user consent. In an aspect, the transactional messages refer to automated messages that provide information related to user’s activity, for example, one-time passwords, order confirmations, or payment alerts. In an aspect, the service messages refer to informational communication messages sent by service providers to notify the users about data, for example, but not limited to, service updates, maintenance alerts or account-related details.

[0098] In an embodiment, the system 108 may be implemented as a messaging as a service (MaaS) platform (interchangeably referred to as a messaging platform) that provides aggregated messaging services to users, such as enterprises. The MaaS platform manages user subscriptions, thereby facilitating efficient and reliable communication between the users and their customers. The MaaS platform can send different types of messages, such as transactional, promotional, services and similar in bulk, to customers.

[0099] In an aspect, each microservice is configured to operate as an independent and containerized service communicating through one or more application programming interfaces (APIs). Each microservice associated with the messaging services in the distributed computing environment is configured to function as an independent and self-contained service entity. Each microservice encapsulates specific functionalities or message-handling operations, such as message generation, routing, delivery, or analytics, and operates autonomously without dependency on the internal states of other services. The independence of each microservice enables modular development, deployment, scaling, and maintenance, thereby enhancing system reliability, fault tolerance, and operational efficiency. Each microservice is implemented as the containerized service within the distributed messaging environment, where the containerized serviceencapsulates its runtime, libraries, configurations, and execution dependencies within an isolated container to ensure uniform deployment and operation across heterogeneous computing nodes. This containerization enables messaging functions, for example, validation, routing, channel adaptation, API processing, and message aggregation, to execute as autonomous, scalable, and portable components that can be independently orchestrated, replicated, or upgraded without affecting other services in the distributed computing environment. For example, the aggregation microservice may be deployed as a container with its own runtime, libraries, configuration files, and API endpoints. The container of the aggregation microservice may be scaled to multiple instances during high message load without modifying or interrupting other containerized services, such as the provisioning microservice and the notification microservice.

[0100] In an aspect, each microservice is deployed within a containerized environment that includes its runtime, execution libraries, and dependencies. The containerization ensures consistent operation across heterogeneous computing infrastructures, simplifies version control, and facilitates seamless orchestration of multiple microservices. This structure also allows dynamic resource allocation and load balancing to meet varying messaging demands in real time.

[0101] Further, the plurality of microservices communicates through one or more Application Programming Interfaces (APIs), which define standardized interfaces for inter-service data exchange and coordination. The use of APIs enables interoperability, scalability, and secure message transfer between distributed components. Through this architecture, the messaging services achieve high scalability, flexible integration with external systems, and efficient management of distributed message processing workflows.

[0102] In an aspect, the microservices communicate with each other through APIs by discovering the target service’s endpoint, constructing an authenticated API request (e.g., Representational State Transfer (REST)ZHyper Text Transfer Protocol Secure (HTTPS)), sending the API request through an API gateway ordirect service call, and allowing the receiving microservice to validate the request, execute its business logic, and return a structured response. For example, when an aggregation microservice needs to verify quota, the aggregation microservice may send a REST API call to the resource management microservice with the user ID and requested message volume. The resource management microservice checks the quota in the database, returns an authorization response, and the aggregation microservice proceeds based on the approval or rejection.

[0103] In an aspect, each of the traffic management microservice 208, the aggregation microservice 216, the notification microservice 212, the resource management microservice 214, the provisioning microservice 210, and the distribution microservice 218 is implemented as an independent microservice configured to operate asynchronously through service APIs, enabling scalability, fault isolation, and independent deployment.

[0104] In an aspect, the plurality of microservices may also communicate through an asynchronous message queue. The asynchronous message queue refers to a communication mechanism that enables microservices to exchange data without requiring both sender and receiver microservices to be active or connected simultaneously. The asynchronous message queue may store messages temporarily in a queue so that the receiving microservice may process them later according to the processing capacity, enabling non-blocking communication, higher scalability, and fault tolerance in the distributed computing environment.

[0105] In an embodiment, the user 102 may send a registration request via the UE 104 over the network 106 to register with the system 108. Once the user 102 is registered with the system 108, the user 102 may initiate a purchase of a messaging service subscription through the provisioning microservice 210.

[0106] In an aspect, the provisioning microservice 210 is configured to manage one or more subscription management operations. The one or more subscription management operations comprise at least one of activation, deactivation, and modification of subscriptions. In an aspect, the activation refers to the operation inwhich the provisioning microservice 210 initiates or enables a new or previously inactive subscription for the messaging service. The activation may include allocating system resources, updating entitlement records, generating configuration artifacts, and enabling routing or delivery pathways required for message transmission. For example, upon receiving an activation request for an enterprise SMS subscription, the provisioning microservice 210 validates the user identity, retrieves the associated service plan, and registers a new messaging endpoint in the delivery microservice. The provisioning microservice 210 further updates a billing part with the activation timestamp and provisions the necessary API keys and throughput quotas required for sending transactional and promotional messages. In an aspect, the deactivation refers to the operation in which the provisioning microservice 210 suspends or terminates an existing subscription, thereby disabling the user or system’s capability to initiate or receive messaging services. Deactivation may involve revoking credentials, withdrawing entitlements, and disabling message routing configurations. For example, when a deactivation request is generated due to account expiration or policy violation, the provisioning microservice revokes the messaging API credentials associated with the user, deregisters the virtual messaging number from the routing microservice, and updates the billing service to cease further charging. All pending or undelivered messages associated with the subscription may be flagged for cancellation or archival according to compliance rules. In an aspect, modification refers to the operation in which the provisioning microservice 210 updates one or more parameters of an active subscription. Such parameters may include service-tier upgrades or downgrades, quota adjustments, feature enablement (e.g., enabling MMS), or policy modifications. For example, the provisioning microservice 210 receives a modification request to upgrade an existing messaging subscription from a basic SMS-only plan to a combined SMS / MMS plan. In response, the provisioning microservice 210 updates the entitlement configuration to include MMS capabilities, recalibrates the message throughput limit, updates the billing cycle to reflect the new subscription tier, and synchronizes the revised configuration with the delivery, storage, and analytics microservices to ensure harmonizedoperation.

[0107] Further, after performing the subscription management operations, the system 108 ensures that users’ credentials are validated by requiring every message transmission request to pass through an authentication layer, secure tokens such as JWT or OAuth2, where the token’s signature, expiry, and assigned permissions are verified against the authorization server. Once the request is authenticated, the provisioning microservice retrieves the user’s subscription record from the database and confirms that the user is entitled to send messages. The database 220 maintains key subscription details including the subscription status (e.g., active, inactive, suspended), allocated and remaining message credits, service validity period, channel permissions (e.g., SMS, email, RCS, etc.), assigned message templates, enterprise identifiers, and usage policies. After any subscription management operation, such as activation, deactivation, or modification, the provisioning microservice updates these fields accordingly to the aggregation microservices 216 rely on accurate subscription data for authorization and routing decisions.

[0108] In an embodiment, the provisioning microservice 210 utilizes a marketplace interface 302 to display a plurality of messaging service subscription plans to the user 102. In particular, the marketplace interface 302 is a dedicated user interface that allows the user 102 to view and manage their messaging service subscriptions. The marketplace interface (e.g., marketplace interface 302 as shown in FIG. 3) allows the users to purchase any messaging service subscription plan from the plurality of displayed messaging service subscription plans or to cancel a purchased messaging service subscription as needed.

[0109] In an aspect, the provisioning microservice 210 stores subscription information (i.e., a purchased messaging service subscription) in the database 220. The subscription information includes details such as subscription level, service duration, associated credentials, the type of subscription (prepaid or postpaid), and the subscription status (active status or inactive status). In at least one example embodiment, the provisioning microservice 210 may also share the subscriptioninformation with the aggregation microservice 216, which may then store it in a local cache or the database 220.

[0110] In an aspect, the notification microservice 212 is configured to generate and transmit one or more notifications associated with at least one subscription activity, system alerts, quota usage to the user or an enterprise system. Upon receipt of any trigger event (e.g., subscription activation, service error, threshold breach), the notification microservice 212 retrieves relevant metadata, including subscription identifiers, usage statistics, user preferences, enterprise routing rules, and message templates. The notification microservice 212 may dynamically assemble a notification payload, apply formatting rules, and select an appropriate delivery channel, such as SMS, email, push message, dashboard alert, webhook callback, or machine-readable event message. The generated notification is then transmitted to the destination user devices using reliable and asynchronous communication protocols. For example, in the subscription activity notification, when a user activates or modifies a subscription, the notification microservice sends an appropriate update, such as the SMS “Your messaging service subscription has been successfully activated. You may now send up to 10,000 messages per month”. In the system alert notification, if a system component experiences a failure, threshold breach, or abnormal behavior, the notification microservice generates alerts, such as “ALERT: the aggregation microservice 216 Instance-3 is unreachable. Failover activated at 11:05 AM. In the quota usage notification, when a user or enterprise approaches or exceeds a quota limit (e.g., message volume, API rate limit), a usage notification is sent automatically to the user / enterprise through the SMS / Email, such as "Your message quota usage has reached 80%. Please upgrade your plan to avoid service interruption”.

[0111] The notification microservice 212 may also log delivery status, perform retries in the event of transmission failure, and update audit or compliance records. The notification microservice 212 ensures the timely and accurate dissemination of system-generated communications related to subscription life-cycle events, system health, and resource consumption metrics across the distributed computingenvironment.

[0112] In an aspect, the asynchronous communication protocols for the messaging services in the distributed computing environment refer to protocols that allow message producers and consumers to operate independently, without requiring both parties to be connected or ready at the same time. The messages are sent, queued, and delivered through intermediaries (e.g., brokers, queues, gateways) so that the microservices may continue processing tasks without waiting for immediate responses. This enables high throughput, resilience, and loose coupling between messaging components, suitable for large-scale SMS, email, push, and OTT messaging systems that may generate millions of requests simultaneously.

[0113] Upon successful provisioning, the notification microservice 212 automatically generates and transmits a message via email and SMS to the user 102, detailing subscription specifics and credentials required for accessing the messaging service. It should be noted that the notification microservice 212 may send multilingual notifications according to the preference of the user 102.

[0114] In an embodiment, the notification microservice 212 is configured to send one or more notifications to the user 102 through a systematic process. Upon triggering events related to subscriptions, such as successful subscription activation, upcoming renewal dates, or service updates, the notification microservice 212 is configured to generate the appropriate notification content. The one or more notifications are dispatched in real-time or scheduled as per the requirements, ensuring that the user 102 remains informed of important subscription-related activities and updates.

[0115] In an embodiment, a traffic management microservice 208 is configured to receive one or more message transmission requests from the user equipments (UEs) 104 ofthe users 102 to send messages to customers. In an aspect, the UEs of the user may comprise phones, feature phones, tablets, laptops, and loT-enabled devices. For example, when the user uses a mobile banking app on their smartphone to request an OTP, the smartphone functions as the UE that sends themessage transmission request to the traffic management microservice 208.

[0116] In an aspect, the message transmission requests refer to discrete, system-generated instructions comprising recipient data, message content, channel identifiers, and associated delivery parameters, the receipt of which initiates processing within the distributed computing environment. Upon generation, each message transmission request is propagated through the microservices configured to perform validation, routing, transformation, queuing, and dispatch operations for effectuating delivery over one or more communication channels. The one or more message transmission requests may serve as a signal, given by the user 102 to the system 108, to initiate the messaging delivery process. The one or more message transmission requests may be sent to transmit at least one of, but not limited to, transactional message (e.g., OTPs, order confirmation), promotional message (e.g., offer, discount), alert message (e.g., warning, fault notification, failure), informational message (e.g., account summary), command message (e.g., trigger task, update cache), control message (e.g., data usage), event message (e.g., user registration, payment process), and communication message (e.g., SMS, Email, MMS). For example, the enterprise (e.g., banking application) generates a message transmission request when a customer attempts to log in. The request contains the customer’s mobile number, user ID, message type ("transactional"), and message content (“Your OTP for login is 482913”). This request is sent to the messaging platform so the platform validates the template, verifies the user’s subscription status, authorizes the request, and delivers the OTP SMS to the customer.

[0117] The traffic management microservice 208 is configured to allocate the one or more message transmission requests across the plurality of aggregation microservices 216 based on one or more parameters. In an aspect, the one or more parameters comprise, but not limited to, workload, message priority, or network conditions. In an embodiment, the traffic management microservice 208 is configured to distribute the traffic of the one or more message transmission requests received from user 102 across one or more instances of the plurality of aggregation microservices 216 through API. The traffic management microservice 208 firstassesses the incoming message transmission request traffic volume, considering factors, for example, total number of SMS queued for sending, peak times, and priority of messages. Based on the analysis, the traffic management microservice 208 determines which instances of the aggregation microservice 216 best handle the current load. This selection may be based on factors, for example, current workload, processing speed, and resource availability. The traffic management microservice 208 then directs each message transmission request or group of message transmission requests to the selected aggregation microservice instance, ensuring that no single instance is overloaded. This real-time traffic management helps in maintaining the efficient delivery of the message transmission requests while minimizing delays. For example, sending 50,000 notifications within two hours requires prioritizing VIP alerts, queuing low -priority messages, and adjusting strategies based on bandwidth and latency for efficient communication.

[0118] In an aspect, the traffic management microservice 208 in the distributed messaging environment primarily relies on standard data structures and routing logic rather than complex algorithms to manage message flow efficiently. The traffic management microservice 208 utilizes queues to temporarily store incoming message requests, maps or dictionaries to hold metadata such as user ID, subscription status, message type, channel, and priority, and lists or arrays to track available aggregation microservices and their real-time load metrics. The traffic management microservice receives requests from user equipment, applications and the enterprise system. The data structures are used to evaluate routing parameters, determine the optimal aggregation microservice, and manage priorities in a scalable and fault-tolerant manner.

[0119] In an aspect, the message transmission requests are exchanged between the microservices via REST APIs or asynchronous message queues. Each message transmission request contains both message content (e.g., SMS text, multimedia payload) and metadata (e.g., message ID, user ID, subscription ID, channel, priority, timestamp, template ID, callback URL). For example, data structure (e.g., a JavaScript Obj ect Notation (J SON) payload) sent to the aggregation microservicemay specify the message ID, channel, content, and target microservice for processing. After the routing decision, the traffic management microservice forwards the request to the selected aggregation service and receives acknowledgments or status updates via APIs or callbacks. This structured approach ensures interoperability between microservices, supports multi-channel delivery, and maintains reliability without relying on complex proprietary algorithms.

[0120] In an embodiment, upon receiving the one or more message transmission requests, each aggregation microservice 216 is configured to extract and verify the user and message information associated with the message transmission requests using data obtained from the provisioning microservice. In an embodiment, each aggregation microservice 216 (or instance of the aggregation microservice) may initiate a query to the provisioning microservice, through the API, to access data corresponding to the received message transmission requests from the local cache or the database 220. Upon accessing the data, each aggregation microservice 216 extracts the user and message information associated with the received message transmission requests. For example, the aggregation microservice 216 may extract user and message information such as user identifiers, contact details, message type, content, delivery channel, priority and metadata.

[0121] Upon extracting the user and message information, the aggregation microservice 216 is configured to verify the extracted user and message information.

[0122] The step of verifying the extracted information of the user comprises:

[0123] Each aggregation microservice 216 is configured to access subscription details corresponding to the user from the database. The subscription details comprise, but are not limited to, one or more of a subscription level, a service duration, subscription credentials, a subscription type and a subscription status. In an aspect, the subscription details collectively define the user’s entitlements, operational permissions, service limits, and validity conditions associated with accessing and utilizing the messaging services. The aggregation microservice 216analyzes the retrieved subscription details to determine whether the incoming message transmission request complies with the subscribed service plan, applicable processing rules, and permitted messaging capabilities. In an aspect, the subscription level may indicate the tier of service allocated to the user, such as basic, standard, or premium. The service duration identifies the start and expiry dates of the subscription. Subscription credentials include authentication artifacts, for example, API keys, tokens, or certificates, required for secure access. The subscription type represents the category or nature of the messaging service subscribed to, such as transactional-only, promotional-only, hybrid, or multichannel messaging. The subscription status reflects the operational state of the subscription, for example, active, inactive or suspended, expired, or pending verification. By interpreting attributes of the subscription details, the aggregation microservice ensures that message requests are processed in accordance with contractual entitlements and system policies.

[0124] The aggregation microservice 216 is configured to match the accessed subscription details with the extracted information of the user to determine whether the subscription status is an active status or an inactive status. In an aspect, the matching of the subscription details with the extracted information of the user comprises steps as follows:

[0125] The aggregation microservice 216 may normalize the extracted information by first formatting and normalizing the user identifiers (e.g., user ID, enterprise ID, subscription ID and channel type) to ensure comparison with stored subscription data. The aggregation microservice 216 may convert the normalized information into a comparable structured format, such as a key-value map or object, to allow direct field-level comparison. The aggregation microservice 216 may then perform field-by-field matching, i.e., comparing each extracted field with the corresponding field in the subscription record to verify that both originate from the same subscriber account. The aggregation microservice 216 may validate subscription plan alignment by checking the plan reference or subscription ID extracted from the message transmission request against the plan identifier storedin the subscription record to confirm that the user is bound to the correct subscription plan. The aggregation microservice 216 may verify Channel configuration consistency by matching the channel specified in the message request (e.g., SMS, RCS, email) with the list of permitted channels in the subscription record to ensure that the requested channel is authorized under that plan. Then, the aggregation microservice 216 may generate a match result. If all fields, i.e., identity, plan information, and channel configuration, are matched, the aggregation microservice 216 determines that the subscription is correctly matched; otherwise, the request is flagged as mismatched and prepared for rejection.

[0126] Upon determining the subscription status is the active status, the aggregation microservice 216 is configured to exchange the extracted information with the resource management microservice 214 for authorization through the API. In an aspect, upon determining that the subscription status is the active status (i.e., the subscriber is allowed to use the messaging services). After confirming the active status, the aggregation microservice 216 may compile all relevant extracted information, such as message payload, enterprise ID, user ID, channel type, template ID, and requested volume, into a structured authorization request. The aggregation microservice 216 transmits the structured authorization request with the information to the resource management microservice 214 through the API or an asynchronous message queue, requesting authorization for resource usage, such as quota, rate limits, or channel allocation.

[0127] Upon determining that the subscription status is inactive, the aggregation microservice 216 is configured to reject the message transmission request.

[0128] For example, when an enterprise requests transmission of a set of promotional SMS messages, the aggregation microservice 216 retrieves the corresponding subscription details from the database. The details may include a standard-level subscription (subscription level), valid from 1 July to 31 December (service duration), associated with a registered API key and secret token(subscription credentials), categorized as a Promotional Messaging Plan (subscription type), and currently marked as active (subscription status). Based on the subscription details, the aggregation microservice 216 verifies that the user is permitted to send promotional messages within the valid time window and using the authorized credentials. If the subscription type were “Transactional-Only” or the status were “Expired,” the microservice would reject the request and generate a compliance error.

[0129] Upon verification, the resource management microservice 214 is configured to determine whether transmission of the message is authorized based on one or more predefined rules. In an aspect, the predefined rules refer to preconfigured policies that are created beforehand by administrators or system designers and are enforced automatically during every access request. The predefined rules ensure consistent, secure, and role-based control over system operation. The predefined rules govern the eligibility of a message for processing and delivery in the distributed messaging environment. In an aspect, the one or more predefined rules comprise, but are not limited to, at least one of balance availability and compatibility check. In the balance availability rule determines whether the user or enterprise possesses sufficient messaging credits, quota, or allocated resources to support the transmission of the requested message. The compatibility check verifies whether the requested message type, format, delivery channel, or message size aligns with the user’s subscription capabilities and system-supported configurations. By applying predefined rules, the resource management microservice 214 ensures that only eligible, properly resourced, and contractually permitted message requests are forwarded to downstream delivery microservices.

[0130] The step of the compatibility check comprises:

[0131] The aggregation microservice 216 is configured to access one or more pre-approved messaging templates from the database 220. In an aspect, the one or more accessed pre-approved messaging templates refer to a set of message formats that have been pre-validated, registered, or authorized by the platform or regulatorybody (e.g., DLT for SMS) and are retrieved by the messaging system at runtime to ensure that outgoing messages strictly match approved content structures. The preapproved messaging templates contain predefined message text, placeholders for dynamic variables (e.g., name, OTP), and associated metadata, such as template ID, category, and sender header. The aggregation microservice 216 fetches and applies these templates before generating or sending messages to maintain compliance, consistency, and fraud prevention.

[0132] The aggregation microservice 216 is then configured to compare each of the one or more message transmission requests with the one or more accessed pre-approved messaging templates. The process steps for comparing each of the one or more message transmission requests with the one or more accessed preapproved messaging templates comprise: the aggregation microservice 216 receives the message transmission request, comprising message body, template identifier (ID) (if provided), sender header, metadata (e.g., enterprise ID, user ID, message category). Upon receiving the message transmission request, the aggregation microservice 216 may access the pre-approved messaging template from a compliance engine or DLT registry. The pre-approved messaging template includes approved text, allowed placeholders and associated template identifiers. The aggregation microservice compares the message transmission request with the accessed pre-approved messaging templates by checking fixed text segments, allowed placeholder, and template ID consistency.

[0133] Upon detecting each of the one or more message transmission requests matches with the one or more accessed pre-approved messaging templates, the aggregation microservice 216 is configured to mark a corresponding message transmission request as a compatible request. The marking of the message transmission request as the compatible request permits the request to proceed to subsequent validation and delivery stages.

[0134] Further, upon detecting each of the one or more message transmission requests that does not match with the one or more accessed pre-approved messagingtemplates (for example, containing unauthorized or altered content), each aggregation microservice 216 is configured to reject the transfer of the message.

[0135] For example, an enterprise submits a transactional OTP SMS request. The aggregation microservice 216 retrieves the pre-approved OTP templates, which may include a fixed header, a six-digit OTP placeholder, and a mandatory regulatory footer. When comparing the incoming transmission message request, the aggregation microservice 216 verifies that the content strictly follows the approved template, i.e., “Your OTP is 123456. Do not share.” If all template conditions match, the request is marked as a compatible request and forwarded for delivery. However, if the enterprise attempts to include extra marketing text, i.e., “Y our OTP is 123456. Buy now and get 20% off!”, the aggregation microservice 216 identifies that the message does not match the pre-approved template and rejects the request to prevent the transmission of non-compliant messaging content.

[0136] In an aspect, the validation of each compatible request is performed to ensure the message to be sent adheres to regularity and organizational policies. The aggregation microservice 216 verifies that the message content, format, and associated metadata conform to mandated guidelines, such as content restrictions, required disclaimers, approved templates, and industry-specific compliance rules. The validation further ensures that the message does not contain unauthorized text, prohibited promotional material, or violations of enterprise branding standards. Through this validation step, the aggregation microservice 216 prevents the dissemination of non-compliant messages and maintains adherence to statutory and internal operational requirements.

[0137] In an aspect, upon verifying that the messaging service subscription of the user 102 is active, the aggregation microservice 216 may exchange the subscription information with the resource management microservice 214. Further, the resource management microservice 214 may perform a check to determine whether an available balance of the user 102 is sufficient to transfer each of the one or more SMS. The available balance refers to the user’s 102 allocated SMS quota,which is a predefined limit of SMS that the user 102 is allowed to send within a given period of time. It should be noted that the available balance varies depending on the purchased messaging service subscription plan. In an aspect, the available balance can be accessed from the database 220. The SMS quota is typically managed by the resource management microservice 214 to ensure that the user’s (enterprise) SMS activity stays within permitted levels based on their subscription plans, usage agreements, or operational policies. In an aspect, if it is identified that the user’s 102 current usage is within the available balance, the resource management microservice 214 permits SMS transmissions. Otherwise, it rejects the transmission of the one or more SMS. In an embodiment, upon determining the availability of sufficient balance, the aggregation microservice 216 is configured to determine whether each of the one or more SMS is compatible with at least one preapproved SMS template.

[0138] In an aspect, the user 102 may be required to separately register themselves with a distributed ledger technology (DLT) 318. The DLT refers to a decentralized data management framework in which message-related records are maintained across the microservices. Each microservice stores a synchronized and cryptographically secured copy of the ledger, thereby ensuring immutability, transparency, and tamper-resistant integrity of message transactions within the distributed computing environment. The distributed ledger technology (DLT) facilitates the recording, verification, and synchronization of messaging events, for example, message creation, validation, routing, authentication, and delivery statuses, across the distributed computing environment. The decentralized nature of the DLT prevents unilateral modification of message records, thereby enhancing trust, auditability, and compliance in multi -entity messaging workflows, further, DLT enables secure inter-service communication by ensuring that each microservice accesses a consistent and verifiable state of message transaction history.

[0139] In an embodiment, to facilitate registration of the user 102 in DLT (e.g., DLT 318 as shown in FIG. 3), a DLT interface is provided, which can be accessedby the user 102 through the user equipment 104. The user 102 may provide user details on the DLT interface for registering with the DLT 318. The user details may include enterprise name, enterprise identifier and the like. Once the user 102 is successfully registered with the DLT 318, the user 102 may create their own SMS templates, which are then stored in a repository. In an embodiment, the repository is the database 220. The created SMS templates are also referred to as pre-approved SMS templates.

[0140] In one aspect, the system 108 is configured to enable operator-controlled DLT compliance, separating messaging services into independent microservices and allowing DLT compliance to be enforced only where required (i.e., for SMS). The aggregation microservice 216 validates headers, templates, and sender IDs against operator-controlled DLT registries without affecting other channels like Email or WhatsApp. This decoupling ensures regulatory compliance for the SMS while preserving flexibility and performance for non-regulated messaging paths.

[0141] In an aspect, each aggregation microservice 216 is configured to perform validation of each message based on one or more pre-approved templates. Each aggregation microservice 216 is configured to perform validation of each message against one or more pre-approved templates defined within the distributed computing environment. The aggregation microservice 216 receives message transmission requests from the traffic management microservice and extracts corresponding message content, metadata, and template identifiers. The aggregation microservice 216 then validates the received message by comparing its structure, permitted text fields, mandatory regulatory content, formatting rules, and contextual attributes against the approved template set. This validation ensures that the message adheres to enterprise branding policies, regulatory requirements, and predefined formatting constraints before being allowed into the downstream processing. In one aspect, the system is configured to apply automated template compliance and fallback channel logic, automatically validating incoming message transmission requests against pre-approved templates to ensure regulatory andenterprise compliance before delivery. If the validation fails or a particular channel becomes unavailable (e.g., SMS blocked or delayed), the fallback logic automatically reroutes the message to an alternative channel, such as Email or push notification. This automation ensures uninterrupted delivery, improves reliability, and helps enterprises maintain effective communication even under failures or compliance restrictions.

[0142] For example, when an enterprise application submits a transactional OTP message, the aggregation microservice 216 retrieves the administrator-approved OTP template, which may include a fixed header, a placeholder for a variable OTP value, and a mandatory compliance footer. The microservice verifies that the message includes only the sanctioned fields, that the OTP placeholder contains a valid code, and that no unauthorized promotional or altered text has been inserted. If the message matches the template definition, the aggregation microservice 216 approves the message and forwards it for delivery. Conversely, if the submitted message includes deviations, for example, additional marketing phrases or missing mandatory content, the aggregation microservice 216 rejects the message and returns a validation-failure response to the enterprise system.

[0143] Further, to check the compatibility of the one or more SMS with the at least one pre-approved SMS template, the aggregation microservice 216 may access the repository of pre-approved SMS templates and compare each of the received one or more SMS with the one or more pre-approved SMS templates, ensuring that all SMS that are to be sent adhere to regulatory guidelines and organizational standards. Upon determining the match between the incoming one or more SMS and the pre-approved SMS templates, the aggregation microservice 216 marks the incoming one or more SMS for delivery. If any SMS of the one or more SMS does not match to any of the pre-approved SMS templates, the respective SMS is flagged for rejection.

[0144] In an embodiment, the aggregation microservice 216 is then configured to transmit the one or more SMS that are marked for delivery to the distributionmicroservice 218 through the API. In an aspect, the distribution microservice 218 is configured to transmit the validated message to one or more destination devices through one or more communication networks. The distribution microservice 218 is configured to facilitate transmission of each validated and authorized message to the corresponding destination device, including but not limited to a mobile terminal, email application, loT endpoint, or enterprise system. Upon receiving the message transmission request from aggregation microservice, the distribution microservice 218 determines an appropriate communication network for delivery. In an aspect, the communication networks refer to the underlying network infrastructures, protocols, and connectivity mechanisms that enable data exchange between microservices, external messaging gateways, client applications, and end-user devices for the purpose of transmitting messages across multiple channels. The one or more communication networks comprise, but are not limited to, a cellular messaging network (SMS / MMS), an internet-based transport channel (email, push notification, or API), or an enterprise messaging interface. In the distributed messaging environment, the communication networks facilitate the transport of message transmission requests, delivery payloads, acknowledgments, and control signals across various microservices. The communication networks may include internal service-to-service networks (such as microservice mesh networks), cloudbased virtual networks, and external telecom or internet networks used to deliver messages over channels such as SMS, email, WhatsApp, or RCS. The communication network ensures reliable, low-latency, and secure interaction between distributed services by using transport protocols such as Hypertext Transfer Protocol Secure (HTTPS), Short Message Peer-to-Peer (SMPP), Message Queuing Telemetry Transport (MQTT), WebSockets, and Simple Mail Transfer Protocol (SMTP), depending on the message channel. These networks enable the messaging platform to route traffic, handle retries, manage load, and maintain end-to-end connectivity from the application layer to the final delivery endpoint.

[0145] The distribution microservice 218 further prepares the message in compliance with the protocol requirements of the selected network by embeddingnecessary metadata such as sender information, timestamps, and routing identifiers. Thereafter, the distribution microservice 218 transmits the message to the designated service provider or gateway and may implement retry logic, alternate routing paths, or traffic balancing techniques to ensure reliable delivery under varying network conditions. Upon completion of the delivery process, the distribution microservice 218 generates and stores delivery-status information for subsequent tracking, auditing, or reporting operations.

[0146] The distribution microservice 218 is configured to transmit the one or more SMS to the desired customers. The distribution microservice 218 may use services of the DLT 318 and a short message service centre (SMSC) 320 for transmitting the one or more SMS to the desired customers. The functioning of the DLT 318 and the SMSC 320 is explained in detail with reference to FIG. 3.

[0147] In an aspect, the aggregation microservice 216 may have multiple instances or deployments within the system 108. These multiple aggregation instances work in parallel to handle large volumes of SMS traffic, balancing the load to prevent overload and ensure efficient, scalable message processing. Each instance can manage a subset of the overall traffic, allowing the system 108 to support high-demand environments and improve message delivery performance.

[0148] In an embodiment, the network management microservice 219 is configured to perform one or more functions corresponding to fault, configuration, accounting, performance and security (FCAPS). In an aspect, the FCAPS for messaging services in the distributed computing environment comprises fault, configuration, accounting, performance, and security management functions that collectively enable the systematic monitoring, control, and optimization of multichannel message processing operations. The FCAPS ensures reliable messaging service delivery by facilitating fault detection, parameter configuration, usage tracking, performance assessment, and enforcement of security and compliance measures. In an aspect, the one or more functions comprise monitoring system faults, maintaining configuration logs, recording messaging accounting data,evaluating performance metrics and enforcing security policies across the distributed computing environment.

[0149] In fault management, the network management microservice 219 is configured to detect, classify, and report one or more system faults occurring within the distributed messaging environment. The network management microservice 219 continuously monitors operational logs, heartbeat signals, messaging queues, and error codes to identify failures such as delivery gateway outages, retry-loop saturation, or microservice unresponsiveness. Upon detection of a fault, the network management microservice 219 generates a fault event, triggers alerts to relevant administrative systems, and may initiate automated corrective actions or recovery workflows. For example, if the SMS delivery microservice becomes unreachable due to a gateway failure, the network management microservice 219 detects repeated delivery errors and marks the gateway as “faulty.” It then generates a fault notification, updates the fault management dashboard, and re-routes pending messages to an alternate SMS provider if configured.

[0150] In the configuration logs management, the network management microservice 219 maintains configuration records for all messaging services, including API settings, routing rules, capacity limits, provisioning parameters, and template controls. The network management microservice 219 logs configuration changes, validates updates, and ensures that all distributed microservices operate using synchronized configuration states. The network management microservice 219 may also store historical configuration versions to enable rollback in case of misconfiguration. For example, when an administrator updates the throughput limit for promotional SMS campaigns from 1,000 messages / second to 2,000 messages / second, the network management microservice 219 records the configuration change, applies it across all related delivery nodes, and stores the previous configuration version for audit and rollback purposes.

[0151] In accounting management, the network management microservice 219 is configured to record and aggregate messaging-related accounting data, such asmessage volume, delivery atempts, successful transmissions, failed transactions, and resource consumption metrics. The recorded accounting data is made available for billing systems, auditing workflows, and enterprise reporting. For example, if an enterprise sends 50,000 promotional emails in a single billing cycle, the network management microservice collects details, including the total number of messages sent, successful deliveries, bounce statistics, and resource usage. It then generates accounting records that the billing microservice uses to calculate monthly charges.

[0152] In performance management, the network management microservice 219 evaluates one or more performance metrics associated with the distributed messaging environment, including message latency, throughput, queue depth, utilization, maximum message processing rate, and response times of each microservice, under different load conditions (e.g., normal load, peak load, sudden traffic surge, burst load, high priority traffic, overload, degraded network condition, outage condition). Based on this evaluation, the network management microservice 219 may identify botlenecks, trigger scaling operations, or recommend performance optimizations. For example, if the network management microservice detects that the aggregation microservice is experiencing increased processing latency due to high incoming traffic, the network management microservice 219 records corresponding performance metrics and triggers auto-scaling instructions to deploy additional instances of the aggregation microservice 216.

[0153] In security management, the network management microservice 219 enforces security policies across all messaging microservices by validating authentication credentials, monitoring API access paterns, detecting anomalous activity, and ensuring compliance with encryption and data-protection policies. It may block unauthorized access atempts, trigger alerts, or temporarily disable compromised API keys.

[0154] In an aspect, in the distributed messaging environment, message content, user data, and subscription information are highly sensitive, and therefore the system implements strict security controls addressing authentication,authorization, encryption, and API protection. The system adopts multi-layered security mechanisms to protect message transmission workflows between microservices and external client systems. The system may employ one of security measures, for example, but not limited to, token-based authentication, encryption, role-based access control (RBAC), and threat protection.

[0155] In the token-based authentication, JSON Web Token (JWT) or open authentication (OAuth) tokens may be used to authenticate all client applications and internal microservice requests. When the user or enterprise system initiates a message transmission request, it is required to present a signed token issued by an authorization server. The microservices validate token integrity, expiry, and assigned scopes before processing the request. For example, an enterprise sending OTP SMS must include a JWT token that certifies its identity and permissions; otherwise, the traffic management microservice rejects the request.

[0156] In the encryption, API calls and inter-microservice communication are protected using Transport Layer Security (TLS) to ensure end-to-end encryption. This prevents interception of message content, user identifiers, subscription details, or routing metadata during transit. Whether the message request flows from the user equipment (UE) to the traffic management microservice or from the aggregation microservice to the external SMSC, TLS ensures that data remains confidential and tamper-proof within the distributed computing environment.

[0157] In the RBAC, the system 108 employs the RBAC to control access to sensitive operational functions, such as subscription retrieval, template management, or message routing configuration. Each microservice is assigned specific roles, such as “message-sender”, “template-manager”, “subscriptioncontroller”, or “system -monitor”, which determine the operations it can perform. For example, only the provisioning microservice role may modify subscription states, whereas the aggregation microservice may merely read subscription status but cannot alter it. This ensures strict authorization boundaries in compliance with security requirements.

[0158] In the threat protection, all external API traffic enters through a secure API Gateway, which applies rate limiting, IP filtering, and threat detection policies to prevent abuse, flooding, and denial-of-service (DoS) attacks. Rate limiting ensures that enterprises or malicious clients cannot overload the system by sending excessive message requests in a short period. For instance, the traffic management microservice may cap promotional campaign requests to 500 messages / second while allowing critical OTP traffic at a higher rate. The system also enforces API authentication rules, blocks malformed requests, and provides a secure entry point to the distributed computing environment.

[0159] The network management microservice 219 is configured to manage the operation and performance of all other microservices, such as the traffic management microservice 208, the provisioning microservice 210, the notification microservice 212, the resource management microservice 214, the aggregation microservice 216, and the distribution microservice 218, within the system 108. In particular, the network management microservice 219 monitors and manages network elements, network element configurations, alarms and services to ensure efficient working of the system 108.

[0160] In an aspect, the traffic management microservice 208 is configured to continuously monitor operational parameters, including, but not limited to, historical and real-time message throughput, latency of microservices, queue depth of pending message transmission requests, network conditions such as bandwidth availability and error rates, priority attributes of incoming message traffic (e.g., transactional, alert, promotional). Based on these parameters, the traffic management microservice 208 performs predictive load estimation using statistical models, moving averages, or a machine learning (ML) model. The predicted load is then utilized to allocate message transmission requests across a plurality of aggregation microservices, thereby minimizing latency and preventing resource saturation.

[0161] In an aspect, the traffic management microservice 208 is configured toapply the machine learning (ML) model to perform one or more traffic management operations across the distributed messaging environment. The ML model is trained on historical and real-time messaging data, for example, message volume, routing paths, delivery latency, network load, and resource utilization, to dynamically predict traffic patterns and optimize system behavior. The traffic management microservice 208 operates as an autonomous, containerized service, communicating with delivery, aggregation, provisioning, and scaling microservices through one or more APIs.

[0162] The one or more traffic management operations comprise at least one of message traffic prediction, message routing and resource allocation. By intelligently predicting incoming message loads, the traffic management microservice 208 proactively adjusts routing strategies and distributes traffic across multiple gateways or microservice clusters. The traffic management microservice 208 further determines optimal allocation of computational or network resources to maintain low latency, prevent congestion, and ensure efficient handling of transactional, promotional, and alert-based messaging workloads.

[0163] In the message traffic prediction, the traffic management microservice 208 applies the ML model to forecast expected message volume based on temporal patterns, enterprise activity, seasonal trends, and live traffic signals. This prediction allows the system to prepare resources and avoid congestion before high-load conditions occur. For example, if the ML model predicts a surge of 2 million OTP messages during a flash-sale event, the traffic management microservice 208 preemptively scales up the aggregation and delivery microservices, allocates additional compute nodes, and increases queue capacity to handle the anticipated traffic.

[0164] In the message routing, the ML model analyzes delivery performance metrics such as gateway latency, success rates, peak load, and processing delays to determine the optimal routing path for each outgoing message. The traffic management microservice 208 selects the most efficient route in real time. For example, if the ML model identifies that SMS Gateway A is experiencing risinglatency while Gateway B shows better throughput, the traffic management microservice dynamically reroutes OTP and transactional messages to Gateway B to maintain low response times and high delivery reliability.

[0165] In the resource allocation, the traffic management microservice 208 performs intelligent allocation of processing resources, network bandwidth, and queue capacity. The ML model determines resource demands and instructs the orchestration platform to allocate, scale, or rebalance resources as needed. For example, when promotional email traffic increases by 300% due to a festival campaign, the traffic management microservice 208 allocates additional compute pods to the email delivery service, increases the thread pool for message processing, and adjusts bandwidth allocation to prevent bottlenecks in the environment.

[0166] In an aspect, the system 108 is configured to support multi-channel messaging (e.g., Email, WhatsApp, RCS) and multi -protocol handling. The multichannel messaging refers to a system’s ability to send and manage communications across multiple platforms, enabling the same message request, for example, OTP, alert, or promotion, to be delivered through different channels based on user preference, delivery rules, or fallback logic. The multi-protocol handling allows the system to interpret and operate with the distinct technical protocols used by each channel, for example, simple mail transfer protocol (SMTP) for email, short message peer-to-peer protocol (SMPP) or hypertext transfer protocol (HTTP) APIs for SMS, WhatsApp Business API for WhatsApp, and GSMA Universal Profile APIs for RCS.

[0167] The system 108 is configured to support multi-channel messaging by allowing each microservice to handle one or more messaging channels, such as Email, WhatsApp, RCS, SMS, or push notifications. The traffic management and aggregation microservices route messages dynamically based on the channel specified in the message transmission request, while channel-specific adapters or gateways manage protocol differences, such as SMTP for Email, HTTPS APIs for WhatsApp, or RCS protocols for rich messaging. The system’s multi-protocolhandling ensures that each message is correctly formatted, authenticated, and delivered according to the technical requirements of its target channel, enabling seamless communication across heterogeneous messaging platforms while maintaining compliance, routing efficiency, and monitoring capabilities. Together, these capabilities ensure that the system may format, authenticate, route, and deliver messages seamlessly across heterogeneous channels, despite variations in the transport protocols, payload formats, and integration interfaces.

[0168] Furthermore, the system 108 supports multiple protocols, SMTP, SMPP, HTTP, WhatsApp API, and GSMA UP API. To support multiple protocols, the system 108 may employ a protocol abstraction layer or a dedicated encoder / decoder microservice to handle differences across channels and protocols. The protocol abstraction layer ensures that incoming message transmission requests are converted into protocol-compliant payloads and headers before delivery. For example, text messages may be converted between GSM-7 and Unicode encoding depending on the recipient’s device and network, while binary or multimedia payloads are appropriately packaged for MMS or RCS. The abstraction layer also manages protocol -specific headers, such as message type, sender ID, and delivery receipt flags, ensuring they conform to the requirements of the target gateway or API. Authentication for each channel is handled within the protocol abstraction layer, such as SMS messages use SMSC credentials, WhatsApp messages use certificates and OAuth tokens, and email uses SMTP authentication. By centralizing protocol translation, encoding conversion, and authentication, the system 108 allows the traffic management and aggregation microservices to operate independently with respect to channel differences, enabling seamless, secure, and compliant multi-channel message delivery.

[0169] In an aspect, the system 108 may further comprise an orchestration layer that dynamically selects the optimal channel, applies channel-specific encoding, manages retries, and balances traffic based on network conditions and message priority, ensuring seamless communication across diverse platforms without manual intervention.

[0170] The system 108 may employ notification mechanisms that are used to generate, format, route, and deliver messages or alerts to users, devices, or enterprise systems. The notification mechanisms ensure that important information, such as subscription updates, system alerts, quota usage, or event triggers, is communicated reliably, securely, and in a timely manner across one or more communication channels (e.g., SMS, Email, app push, voice messages). The system 108 may also protect cross-channel notification mechanisms by ensuring that notifications related to subscription activities, system alerts, or quota usage are reliably delivered across multiple messaging channels, rather than being limited to SMS. The notification microservice formats, encodes, and authenticates messages for each channel, while the protocol abstraction or encoder / decoder layer handles channel-specific requirements such as headers, payload formats, and encoding standards. As a result, the system 108 expands coverage beyond SMS to include Email, app push notifications, and voice messages, allowing users and enterprise systems to receive timely and consistent notifications through their preferred or available channels. This multi-channel approach enhances delivery reliability, ensures cross-channel consistency, and prevents dependence on any single communication medium. In this manner, the system 108 both safeguards crosschannel notification mechanisms and extends coverage beyond SMS to Email, app push, and voice messaging.

[0171] In an aspect, the system 108 is configured to employ the ML engine for unified quota and throttling across multiple messaging protocols. The system 108 centralizes usage monitoring and rate control into the ML engine that applies uniform quota checks, rate limits, and flow-control policies regardless of the messaging protocol being used. Whether the traffic is sent via SMPP, SMTP, HTTPS, or OTT APIs, the ML engine monitors message counts, credits, and throughput and dynamically throttles or prioritizes traffic to avoid overload, ensure fairness, and maintain service-level agreements across all channels.

[0172] FIG. 3 illustrates a system architecture 300 configured for providing messaging services, in accordance with an embodiment of the present disclosure.FIG. 3 is explained in conjunction with FIGS. 1 and 2.

[0173] In an embodiment, the system architecture 300 comprises the user 102, the marketplace interface 302, an enterprise provisioning gateway (EPG) 304, a front-end (FE) user interface 306, network management system (NMS) 308, a command-line interface (CLI) 310, the aggregation microservice(s) 216, a load balancer (LB) 312, a quota and throttling manager (QM) 314, a notification engine 316, a distributed ledger technology (DLT) 318, a short message service center (SMSC) 320, a mail server 322, and the database 220.

[0174] In an aspect, the marketplace interface 302 is a centralized interface that allows the user 102 to interact with the EPG 304, to browse, purchase, manage, and modify messaging services such as prepaid subscriptions, postpaid subscriptions and the like. The marketplace interface 302 may include a self-care portal where the user 102 may control their subscriptions and view the subscription information. In an embodiment, the user 102 may purchase a subscription to use the system 108 via the marketplace interface 302.

[0175] In an aspect, the EPG 304 serves as a gateway that provisions and manages prepaid and postpaid subscriptions via the marketplace interface 302, enabling the user 102 to activate and configure their messaging services. In an aspect, the messaging services may comprise short message service (SMS).

[0176] Additionally, the EPG 304 enables the enterprise user 102 to view and manage their subscriptions through a marketplace self-care portal. The EPG 304 also manages authorization and subscription information of the user 102 needed for the messaging service (e.g., SMS delivery). The EPG 304 and the marketplace interface 302 communicate via a hypertext transfer protocol (HTTP) interface. The HTTP interface provides a standardized and secure interface for managing subscriptions and provisioning, enabling the user 102 to interact with the marketplace interface 302. The EPG 304 accesses the database 220 to store and retrieve subscription information of the user 102, including prepaid and postpaid plan information. The EPG 304 is similar to the provisioning microservice 210explained with reference to FIG. 2

[0177] In an aspect, the FE 306, manages the configuration, alarms and data transfers occurring within the system 108 (MaaS platform). The FE 306 also monitors all the microservices / interfaces of the system 108. In particular, the FE 306 monitors network elements and services, enabling alerts, fault management, and troubleshooting, further ensuring that the services run smoothly. The FE 306 is connected to the EPG 304 via the HTTP interface for managing user accounts. The FE 306 is similar to the network management microservice 219, explained with reference to FIG. 2.

[0178] In an aspect, the NMS 308 is a user interface layer for the FE 306. The NMS 308 enables an administrator to view, edit, update and delete configuration, alarms and counters of all the microservices via the FE 306. The NMS 308 is connected to the FE 306 via the HTTP interface to enable viewing, editing, updating, and deletion by the FE 306. e In an aspect, the CLI 310 is text-based interface that may provide access to system administrators for backend configurations, troubleshooting tools, and maintenance operations. The CLI 310 may send a text-based command to the FE 306 via a Transmission Control Protocol (TCP) interface. The use of TCP allows for direct and stable command-line access for system administrators, facilitating low-level control and configuration.

[0179] In an aspect, the aggregation microservice 216 functions as a network component that manages the aggregation and delivery of the one or more messages. The aggregation microservice 216 is configured to integrate with multiple network operators to route message (e.g., SMS), manage message templates, and perform smart scrubbing of message (e.g., SMS) content against pre-approved templates before delivery to the intended customers. The aggregation microservice 216 retrieves the pre-approved message template (e.g., SMS templates) from the database 220, which are then used for compliance checks against DLT requirements. The user 102 interacts with the aggregation microservice 216 over the HTTP interface or Short Message Peer-to-Peer (SMPP) interface to facilitatethe transmission of the one or more messages (e.g., SMSs) to the DLT 318.

[0180] In an aspect, the QM 314 maintains quota and throttling -related data to serve the user with available quota. The QM 314 ensures that the user account does not exceed its messaging quotas and enforces throttling limits to prevent the overuse of system resources. The QM 314 checks available message balance and enforces rate limits on the delivery of the one or more messages (e.g., SMSs). The QM 314 may access the database 220 to maintain and verify real-time quota information for the user 102, including the available balance and rate limits. The QM 314 may communicate with the aggregation microservice 216 via a GPRC framework or interface. The GPRC is a cross-platform, high-performance remote procedure call framework that efficiently connects with the aggregation microservice 216. The GRPC provides high-performance communication between the aggregation microservice 216 and QM 314, supporting balance checks, and enforcing messaging quotas and throttling limits. The QM 314 is similar to the resource management microservice 214, explained with reference to FIG. 2

[0181] In an aspect, the NE 316 is configured to generate and send notifications (via SMS, email) to the user 102 regarding account events, such as subscription activations, expirations, and updates. The NE 316 keeps the user 102 informed about their subscription status. The EPG 304 is connected to the NE 316 via the HTTP interface. This connection allows the EPG 304 to relay subscription updates to the NE 316, triggering relevant notifications to the user 102. The NE 316 is similar to the notification microservice 212, explained with reference to FIG. 2

[0182] In an aspect, the DLT 318 is a regulatory compliance layer required for message authentication and verification. The DLT 318 checks each SMS (e.g., message) against a list of DLT- approved templates (also referred to as the preapproved message templates) (e.g., SMS templates), ensuring that only compliant messages (e.g., SMS are sent to intended customers. Upon verifying that the available balance of the user 102 is sufficient to proceed with the message (e.g., SMS) delivery process, the aggregation microservice 216 sends the one or moremessages (e.g., SMSs) to the DLT 318 to perform matching between the SMS template and the list of DLT approved templates.

[0183] In an aspect, the SMSC 320 is a network component that is responsible for the delivery of one or more messages (e.g., SMS) to the intended customers. The SMSC 320 may deliver the one or more messages (e.g., SMS) to the intended customers by routing them to the intended destination, ensuring successful message delivery. The NE 316 communicates with the SMSC 320 over the SMPP interface to notify the user 102 about the successful message (e.g., SMS) delivery. A notification may be sent to the user 102 informing about the successful delivery of the one or more messages (e.g., SMS).

[0184] In an aspect, the mail server 322 is a network component that supports email-based communication, allowing the system 108 to send notifications or other types of alerts to the user 102 via email. The mail server 322 works in conjunction with the NE 316 and is connected via Simple Mail Transfer Protocol (SMTP) interface.

[0185] In an aspect, the system architecture 300 may also comprise the load balancer 312 for distributing the traffic of one or more messages (e.g., SMS) to multiple instances of the aggregation microservice 216. In the distributed computing environment, the load balancer is situated between incoming message transmission requests and the aggregation microservices 216. The load balancer 312 continuously receives message transmission requests from the traffic management microservice 208 and routes them to one of the instances of the aggregation microservices 216 based on a load-balancing logic. The load balancer 312 ensures that no single aggregation microservice becomes overloaded by examining routing rules, node availability, and system performance metrics before forwarding each request. The load balancer 312 also performs real-time health checks to confirm that only active and healthy aggregation microservices receive traffic. By distributing traffic efficiently, the load balancer 312 ensures optimal throughput, prevents bottlenecks, and maintains high availability. The load balancer 312 mayapply a load balancing logic, such as, but not limited to, a round-robin load balancing logic, a machine-learning scoring (MLS) load balancing logic, and a failover load balancing logic. In one aspect, the round-robin load balancing logic implemented by the load balancer maintains a rotating pointer over the list of available instances of the aggregation microservice and assigns each incoming message request to the next instance in sequence. Each time the message transmission request arrives, the pointer advances to the following aggregation microservice, and when the end of the list is reached, the pointer wraps around to the beginning. This creates a uniform and predictable distribution of the message transmission requests across all instances of the aggregation microservices.

[0186] In an aspect, the MLS-based load balancing logic uses real-time machine load scoring to determine the best aggregation microservice for each message transmission request by analyzing operational metrics, such as processing unit usage, memory consumption, queue length, processing latency, and success rate. The load balancer collects the operational metrics from each instance of the aggregation microservice and calculates a weighted score, where a lower score indicates a more optimal and less congested node. Incoming message requests are dynamically routed to the aggregation microservice with the lowest MLS score, ensuring that traffic flows toward the aggregation microservice with available capacity. This adaptive method improves throughput, prevents overload, and is ideal for performance-critical messaging environments with highly variable loads.

[0187] In an aspect, the failover load balancing logic prioritizes high availability by designating a primary aggregation microservice for routing and continuously monitoring all aggregation microservices through health checks such as heartbeat signals and status probes. If the primary aggregation microservice becomes unresponsive or exceeds error thresholds, the load balancer automatically shifts incoming requests to a pre-assigned backup aggregation microservice to maintain uninterrupted processing. Once the failed aggregation microservice recovers, traffic is automatically redirected to the primary aggregation microservice (fallback) or continues to use the backup aggregation microservice until manualintervention, depending on the configuration. This ensures seamless service continuity even when individual aggregation microservice fails.

[0188] FIG. 4 illustrates an exemplary process flow 400 for providing messaging services, in accordance with an embodiment of the present disclosure. FIG. 4 is explained in conjunction with FIGS. 2 and 3.

[0189] At step 402, the notification engine 316 sends one or more messaging notifications, such as SMS or email notifications, to the user 102, wherein the one or more notifications include information related to the enterprise’s subscriptions.

[0190] In an aspect, the NE 316 also sends updates to the user 102 about subscription-related events, such as activation, renewal, cancellation, or modification of prepaid and postpaid subscriptions. This helps in keeping the enterprise informed about the status of the messaging services.

[0191] At step 404, the user 102 sends one or more messages (e.g., SMS) to the aggregation microservice 216 for delivery to the DLT 318. The one or more messages (e.g., SMS) may include promotional messages, transactional messages, service messages or similar messages from the enterprise.

[0192] At step 406, the EPG 304 may send the subscription information (for example, prepaid or postpaid subscription status) to the aggregation microservice 216 to confirm that the user 102 has an active and valid subscription, authorizing it to send the one or more messages (e.g., SMS). In an aspect, the EPG 304 may prompt the aggregation microservice 216 to initiate the message (e.g., SMS) delivery process based on the user’s 102 current subscription status and configuration. The EPG 304 also sends account provisioning details to the aggregation microservice 216.

[0193] At step 408, the aggregation microservice 216 sends a request to the QM 314 for balance check verification or quota check to verify if the user 102 has enough available balance or quota remaining to send the one or more messages(e.g., SMS) to the DLT 318, ensuring that messaging limits or prepaid credits are not exceeded.

[0194] In an aspect, the aggregation microservice 216 may perform a check with the QM 314 to confirm that the rate of messaging (e.g., messages per second) adheres to the throttling limits, ensuring smooth operation without overloading the system 300.

[0195] At step 410, the aggregation microservice 216 verifies whether the available balance is sufficient for proceeding the message delivery.

[0196] If it is determined that the available balance is insufficient, the process follows branch "No" from step 410, and at step 412, the messages (e.g., SMS) are rejected by the aggregation microservice 216.

[0197] Alternatively, if it is determined that the available balance is sufficient, the process follows branch "Yes" from step 410. At step 414, the aggregation microservice 216 performs an additional check to verify whether the templates used in the one or more messages (e.g., SMS) matches with any of the pre-approved messaging template (e.g., SMS templates).

[0198] If the template of the one or more messages (e.g., SMS) does not match with any of the pre-approved message templates (e.g., SMS templates), the process follows branch "No" from step 414, and at step 416, the aggregation microservice 216 rejects the one or more messages (e.g., SMS).

[0199] Alternatively, if the template of one or more messages (e.g., SMS) matches any of the pre-approved SMS message templates (e.g., SMS templates), the process follows branch "Yes" from step 414, and at step 418, the one or more messages (e.g., SMS) are sent to DLT 318.

[0200] In an aspect, the DLT compliance is enforced for SMS messaging. The SMS message is checked against approved templates stored on the DLT before passing through the SMSC for delivery. Further, for other messaging (i.e., Email,RCS, WhatsApp, push notification, OTT channels) that operate over internet-based platforms are controlled by platform-level policies. The platform uses an internal template validation engine, business rules, and platform-level compliance checks.

[0201] FIG. 5 illustrates an exemplary flow diagram 500 of a method for providing messaging services, in accordance with an embodiment of the present disclosure.

[0202] At step 502, the method 500 includes receiving, by the traffic management microservice 208, one or more message transmission requests from one or more user equipments (UEs) 104. In an aspect, the message transmission requests are sent by the user for the messaging services. The messaging services comprise, but not limited to, at least one of short messaging service (SMS), electronic mail (email), multimedia message (MMS), rich communication service message (RCS), an instant message, promotional messages, transactional messages, and service messages.

[0203] At step 504, the method 500 includes allocating, by the traffic management microservice 208, the one or more message transmission requests across a plurality of aggregation microservices based on one or more parameters. In an aspect, the one or more parameters comprise, but are not limited to, workload, message priority, or network conditions. In an aspect, upon receiving the message transmission requests from the UEs, the traffic management microservice 208 assesses the parameters, i.e., workload (e.g., pending requests at the aggregation microservice), message priority (e.g., high-priority, low-priority) and the network conditions (e.g., bandwidth availability, latency, packet loss, network congestion, health (i.e., overload, temporarily unavailable), and routing path stability). By evaluating the one or more parameters in real time, the traffic management microservice 208 ensures optimal utilization of system resources and prevents congestion at any single aggregation node. This allocation mechanism helps maintain consistent performance, reduce latency, and prioritize high-importance messages within the distributed messaging environment.

[0204] At step 506, the method 500 includes extracting and verifying, by each aggregation microservice 216, user and message information associated with the message transmission requests using data obtained from the provisioning microservice 210. To verify the extracted information of the user, the aggregation microservice retrieves subscription details corresponding to the user from the database or the provisioning microservice 210. The provisioning microservice 210 may analyses the transmission message requests and then extract the subscription details corresponding to the transmission message requests from the database 220. The subscription details comprise one or more of a subscription level, a service duration, subscription credentials, a subscription type and a subscription status. The aggregation microservice matches the accessed subscription details with the extracted information of the user to determine whether the subscription status is an active status or an inactive status. Upon determining that the subscription status is the active status, the aggregation microservice 216 exchanges the extracted information with the resource management microservice 214 for authorization. Upon determining that the subscription status is inactive, the aggregation microservice 216 rejects the message transmission request.

[0205] At step 508, the method 500 includes, upon verification, the resource management microservice 214 is configured to determine whether transmission of a message is authorized based on one or more predefined rules. In an aspect, the one or more predefined rules comprise, but are not limited to, at least one of balance availability and compatibility check. The resource management microservice 214 checks the balance availability by checking, such as remaining message credits, quota, or prepaid balance required to send the message. The resource management microservice 214 confirms that the message transmission request has passed the compatibility check, i.e., the message content, format, and type meet the system’s predefined policies or templates. When both conditions are satisfied, the resource management microservice 214 authorizes the message for further processing and delivery.

[0206] In an aspect, to perform the compatibility check, the aggregationmicroservice 216 accesses one or more pre-approved messaging templates from the database. The aggregation microservice 216 then compares each of the one or more message transmission requests with the one or more accessed pre-approved messaging templates. Upon detecting each of the one or more message transmission requests matches with the one or more accessed pre-approved messaging templates, the aggregation microservice 216 marks a corresponding message transmission request as a compatible request. Further, upon detecting each of the one or more message transmission requests that do not match with the one or more accessed preapproved messaging templates, the aggregation microservice 216 rejects the transfer of the message.

[0207] At step 510, the method 500 includes performing, by each aggregation microservice 216, validation of each message based on one or more pre-approved templates. In an aspect, the aggregation microservice 216 performs validation of the message by comparing its content, format, and structure against one or more pre-approved messaging templates stored in the database. The messaging templates define standardized message formats that comply with regulatory requirements, organizational policies, language rules, and content restrictions. During validation, the aggregation microservice 216 checks whether the message includes all required fields (such as sender ID, header, body text), follows permitted wording, and matches the allowed message type (promotional, transactional, or alert). If the message aligns with the approved template, the aggregation microservice 216 classifies it as a valid and compliant request, allowing the message to proceed in the processing pipeline. If no match is found, the message is flagged as non-compliant and is rejected to prevent unauthorized or unregulated message delivery.

[0208] At step 512, the method 500 includes transmitting, by the distribution microservice 218, the validated message to one or more destination devices through one or more communication networks. In an aspect, the distribution microservice 218 is responsible for delivering each validated message to its intended destination device (e.g., a mobile phone, email client, loT device, or enterprise system). After receiving the message that has passed all validation and authorization checks, thedistribution microservice 218 selects the appropriate communication network required for delivery, which may include cellular networks (SMS / MMS), internetbased channels (email, push notifications, APIs), or enterprise messaging gateways. The distribution microservice 218 may format the message according to the protocol of the selected network, attach necessary metadata (sender ID, timestamps, routing information), and then transmit it to the corresponding service provider or network gateway. The distribution microservice 218 may also apply retry mechanisms, fallback routing, or load balancing to ensure successful delivery even when network conditions fluctuate. Once the message reaches the one or more destination devices, the distribution microservice 218 records the delivery status and updates the system for tracking and auditing purposes.

[0209] In an aspect, the method comprises generating and transmitting, by a notification microservice 212, one or more notifications associated with at least one subscription activity, system alerts, quota usage to the user or an enterprise system. The notification microservice 212 continuously monitors subscription-related events, system-level conditions, and quota utilization metrics received from other microservices, including the traffic management microservice 208, the provisioning microservice 210, the resource management microservice 214, and the network management microservice 219. Upon detecting at least one subscription activity, for example, activation, renewal, modification, or impending expiry, the notification microservice 212 is configured to generate a corresponding notification message. The generated notification includes structured information such as subscription identifiers, timestamps, status updates, and recommended user actions. Further, the notification microservice 212 is configured to generate system alerts when abnormal behavior, service disruptions, or policy violations are detected within the distributed computing environment. These alerts may be triggered by parameters including processing failures, resource exhaustion, or connectivity errors. Additionally, the notification microservice 212 computes quota usage information by aggregating consumption data (e.g., message count, API usage, or credit consumption) and generates notifications when usage thresholds are reachedor exceeded. The notification microservice 212 continuously monitors the consumption data against predefined thresholds specified in the subscription plan or system policies. When a threshold is reached or exceeded, the notification microservice 212 constructs and sends a notification to inform the user or enterprise system. Once the notifications are generated, the notification microservice 212 transmits these notifications through one or more communication channels, for example, SMS, email, dashboards, or enterprise APIs, directly to the user or the enterprise system. For example, a user has a monthly SMS quota of 10,000 messages. The notification microservice aggregates the message count and detects that the user has sent 8,000 messages, reaching 80% of the quota. The notification microservice then generates a notification, such as "Alert: You have used 80% of your monthly SMS quota. Only 2,000 messages remaining. Consider upgrading your plan to avoid interruption. This notification is sent via SMS, email, or in-app alert, depending on the system configuration.

[0210] The notification microservice 212 also applies routing rules, delivery prioritization, and retry mechanisms to ensure the timely and reliable dissemination of the notifications.

[0211] In an aspect, the method comprises performing, by the network management microservice 219, one or more functions corresponding to fault, configuration, accounting, performance and security (FCAPS). The one or more functions comprise monitoring system faults, maintaining configuration logs, recording messaging accounting data, evaluating performance metrics and enforcing security policies across the distributed computing environment. In an aspect, the network management microservice 219 monitors system faults by detecting component failures, service interruptions, or abnormal message processing behavior. The network management microservice 219 maintains configuration logs that record changes to service parameters, microservice deployments, or network settings for audit and rollback purposes. The network management microservice 219 also records messaging accounting data, including message volume, resource consumption, and usage timestamps, for billing andanalytics purposes. Additionally, the network management microservice 219 evaluates performance metrics such as throughput, latency, and microservice workload to identify bottlenecks or degradation. Further, the network management microservice 219 enforces security policies by validating access permissions, detecting unauthorized activities, and ensuring compliance with regulatory requirements across the platform.

[0212] In an aspect, the method comprises managing, by the provisioning microservice 210, one or more subscription management operations. In an aspect, the provisioning microservice 210 is configured to manage the one or more subscription management operations by the following steps:

[0213] The provisioning microservice 210 first receives the subscription-related request (activation, deactivation, or modification) from the traffic management microservice via the aggregation microservice. The provisioning microservice 210 may perform validation and authorization by verifying the subscription details corresponding to subscription-related requests, for example, by checking whether a subscription exists, confirming eligibility rules (e.g., plan availability and status constraints), and determining whether the requester is authorized. Invalid or unauthorized requests are rejected with an appropriate response code. The provisioning microservice 210 may further fetch the current subscription state from the internal subscription datastore or configuration repository. This step is performed to determine whether the subscription is currently active, inactive, or in a pending state, enabling correct branching logic for the operation.

[0214] Based on the current subscription determination and the requested operation, the provisioning microservice 210 executes one of the subscription management operations. The one or more subscription management operations comprise at least one of activation, deactivation, and modification of subscriptions. During activation, the provisioning microservice 210 validates user credentials, allocates required service resources, and updates the subscription status to allowmessage transmission. During deactivation, the provisioning microservice 210 disables the user’s ability to use messaging services by revoking access credentials and marking the subscription as inactive in the database. During modification, the provisioning microservice 210 updates subscription parameters, for example, plan level, quota limits, service validity, or feature sets, based on user requests or enterprise policies. These operations ensure that only authorized and properly configured users can access and utilize the messaging platform. Further, the provisioning microservice 210 may notify other microservices, such as the resource management microservice and the traffic management microservice, about the subscription changes through the API. Finally, the provisioning microservice 210 may send a response back to the user, through the notification microservice, to inform about whether the operation succeeded or failed, along with updated subscription details or error information.

[0215] The traffic management microservice 208 is configured to apply a machine learning (ML) model to perform one or more traffic management operations. The one or more traffic management operations comprise at least one of message traffic prediction, message routing and resource allocation. In an aspect, the machine learning (ML) model analyzes historical traffic patterns, real-time message loads, user behavior, and network statistics to generate message traffic predictions, for example, estimating peak messaging periods or forecasting potential congestion. Based on these predictions, the traffic management microservice 208 performs message routing. The traffic management microservice 208 dynamically selects optimal aggregation or distribution microservices to ensure balanced processing, reduced latency, and avoidance of overload conditions. Additionally, the traffic management microservice 208 performs resource allocation by assigning compute, storage, or bandwidth resources to different microservices according to predicted demand levels. Through these ML-driven operations, the system 108 maintains efficient, stable, and scalable message processing even under fluctuating traffic conditions.

[0216] In an aspect, the traffic management microservice may use ML models,for example, a supervised time-series forecasting model (e.g., Long Short-Term Memory (LSTM) neural network, AutoRegressive Integrated Moving Average (ARIMA)-based predictor) or a reinforcement learning (RL) model for dynamic routing decisions. In the aspect, the time-series ML models predict future message traffic volume, peak load periods, and channel load. The reinforcement learning models learn optimal routing and resource allocation strategies based on historical outcomes and real-time feedback.

[0217] The ML model is trained using data generated by the microservices. Training data may include, but is not limited to, historical message traffic logs (per second / minute / hour volume), queue length and microservice load metrics, routing decisions and resulting delivery latency, user activity patterns (e.g., OTP spikes during login hours), channel-specific performance data (e.g., SMS latency, WhatsApp throughput, email processing time), network conditions (e.g., carrier bandwidth, node availability), user behavior patterns (e.g., OTP requests at login, bulk campaign requests from enterprise systems, notification bursts triggered by events), metrics from network management microservice (e.g., SMSC availability, gateway performance, carrier network congestion, recent failure, overload conditions), operational data (e.g., current available resource, scaling levels, thresholds), and failure patterns (e.g., microservice downtime, retries, errors).

[0218] During the training process, the ML model cleans, aggregates, and converts the historical datasets into features (e.g., traffic per minute, peak hours, message type ratios). The time-series predictor learns patterns of traffic surges, enabling forecasting. The RL model learns which routing decisions produced the lowest latency or highest throughput, adjusting weights based on rewards.

[0219] In a prediction process, the ML model receives real-time inputs, such as current message rate, active channels, aggregation microservice workloads, latency metrics, subscription type and message priority. The ML model then outputs expected traffic load in the next time window (e.g., “Traffic will spike by 35% in the next 5 minutes”, “Bulk promotional traffic is expected at 10 AM”),recommended routing decision (e.g., “route high-priority messages to instance C of the traffic management microservice), and resource allocation instructions (e.g., “scale up the aggregation microservice-B by 2 pods”).

[0220] Based on the predication and the real-time data, the ML model may choose the most efficient aggregation microservice. For example, routing OTP to low-latency distribution microservice, and route bulk messages to high-throughput aggregation microservices.

[0221] In resource allocation, the ML model may employ auto-scaling, load redistribution, and pre-emptive throttling for non-critical campaigns

[0222] The auto-scaling dynamically increases computing resources, for example, launching additional aggregator microservice pods, when message traffic begins to rise beyond predefined thresholds. The ML model continuously monitors real-time metrics, for example, queue length, CPU usage, and predicted traffic load, and when the ML model anticipates a surge (e.g., a large OTP spike during peak login hours), it automatically instructs the orchestration layer to deploy additional aggregation microservice’s instances. This ensures that the messaging pipeline maintains stable throughput and avoids delays, even during sudden or unpredictable traffic increases.

[0223] The load redistribution includes shifting message processing tasks from heavily loaded aggregation microservices to those with lighter workloads. When the ML model detects uneven load distribution, such as one aggregation microservice experiencing high latency or nearing capacity, the ML model recomputes optimal routing and reassigns upcoming message requests to healthier aggregation microservice. For example, if aggregation microservice-A becomes overloaded due to a bulk promotional campaign, the system may shift part of the traffic to aggregation microservice-C and aggregation microservice-D, thereby preventing performance degradation and ensuring balanced utilization across the distributed computing environment.

[0224] The pre-emptive throttling limits or slows down the rate of low-priority or bulk campaign messages before they cause congestion. If the ML model predicts an upcoming spike in high-priority traffic (e.g., OTPs or system alerts), the ML model proactively reduces the dispatch rate of non-essential messages, such as promotional SMS or marketing emails. For instance, a promotional campaign may be temporarily slowed so that critical OTP messages continue to be delivered instantly. This mechanism protects system performance, preserves latency requirements for essential traffic, and prevents overload conditions before they occur.

[0225] Further, a ML engine periodically re-trains or fine-tunes the ML model using data, such as newly logged message traffic, updated success / failure routing records, recent peak-load behavior, and changing user engagement patterns (e.g., festive-season traffic). This ensures the ML model remains accurate as new traffic trends emerge.

[0226] FIG. 6 illustrates an exemplary computer system 600 in which or with which embodiments of the present disclosure may be implemented.

[0227] As shown in FIG. 6, the computer system 600 may include an external storage device 610, a bus 620, a main memory 630, a read-only memory 640, a mass storage device 650, communication port(s) 660, and a processor 670. A person skilled in the art will appreciate that the computer system 600 may include more than one processor and communication ports. The processor 670 may include various microservices associated with embodiments of the present disclosure. The communication port(s) 660 may be any of an RS-232 port for use with a modembased dialup connection, a 10 / 100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fibre, a serial port, a parallel port, or other existing or future ports. The communication port(s) 560 may be chosen depending on a network, such a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system 500 connects.

[0228] The main memory 630 may be a Random Access Memory (RAM), orany other dynamic storage device commonly known in the art. The read-only memory 640 may be any static storage device(s) e.g., but not limited to, a Programmable Read Only Memory (PROM) chips for storing static information e.g., start-up or Basic Input / Output System (BIOS) instructions for the processor 670. The mass storage device 650 may be any current or future mass storage solution, which can be used to store information and / or instructions. Exemplary mass storage device 650 includes, but is not limited to, Parallel Advanced Technology Attachment (PATA) or Serial Advanced Technology Attachment (SATA) hard disk drives or solid-state drives (internal or external, e.g., having Universal Serial Bus (USB) and / or Firewire interfaces), one or more optical discs, Redundant Array of Independent Disks (RAID) storage, e.g. an array of disks.

[0229] The bus 620 communicatively couples the processor 670 with the other memory, storage, and communication blocks. The bus 620 may be, e.g. a Peripheral Component Interconnect (PCI) / PCI Extended (PCI-X) bus, Small Computer System Interface (SCSI), Universal Serial Bus (USB), or the like, for connecting expansion cards, drives, and other subsystems as well as other buses, such a front side bus (FSB), which connects the processor 670 to the computer system 600.

[0230] Optionally, operator and administrative interfaces, e.g. a display, keyboardjoystick, and a cursor control device, may also be coupled to the bus 620 to support direct operator interaction with the computer system. Other operator and administrative interfaces can be provided through network connections connected through the communication port(s) 660. Components described above are meant only to exemplify various possibilities. In no way should the aforementioned exemplary computer system 600 limit the scope of the present disclosure.

[0231] While the foregoing describes various embodiments of the invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof. The scope of the invention is determined by the claims that follow. The invention is not limited to the described embodiments, versions or examples, which are included to enable a person having ordinary skill in the art tomake and use the invention when combined with information and knowledge available to the person having ordinary skill in the art.

[0232] In an exemplary embodiment, a computer program product comprising a non-transitory computer-readable medium is disclosed. The medium includes instructions that, when executed by one or more processors, cause the one or more processors to execute a method for providing messaging services in a distributed computing environment is described. The method includes receiving, by a traffic management microservice, one or more message transmission requests from one or more user equipment (UEs). The method includes allocating, by the traffic management microservice, on or more message transmission requests across a plurality of aggregation microservices based on one or more parameters. The method includes extracting and verifying, by each aggregation microservice, user and message information associated with the message transmission requests using data obtained from a provisioning microservices. The method includes upon verification, determining by a resource management microservice, whether the transmission of a message is authorized based on one or more predefined rules. The method includes performing, by each aggregation microservice, validation of each message based on one or more parameters. The method includes transmitting, by a distribution microservice, the validated message to one or more destination devices through one or more communication networks.

[0233] The method and system of the present disclosure may be implemented in a number of ways. For example, the methods and systems of the present disclosure may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order for the steps of the method is for illustration only, and the steps of the method of the present disclosure are not limited to the order specifically described above unless specifically stated otherwise. Further, in some embodiments, the present disclosure may also be embodied as programs recorded in a recording medium, the programs including machine-readable instructions for implementing the methods according to the present disclosure. Thus, the present disclosure also covers a recordingmedium storing a program for executing the method according to the present disclosure.

[0234] The present disclosure provides significant technical advancements in scalable messaging services in a distributed computing environment. Enterprises are increasingly utilizing mobile messaging as a primary channel for customer engagement. This medium facilitates the transmission of time-sensitive notifications, order updates, and customer service interactions. In addition to transactional communication, mobile messaging has evolved into a strategic marketing tool, enabling businesses to promote products, attract new customers, and enhance user engagement. To achieve large-scale message delivery, enterprises commonly rely on messaging aggregation microservices. These platforms function as intermediaries between businesses and mobile network operators (MNOs), ensuring reliable message routing across multiple networks and geographic regions. The aggregation microservices manage integration complexities and distribution for promotional, transactional, and service-related communications. While MNOs provide the essential infrastructure for messaging services, their role in revenue generation remains limited. The aggregation microservices capture a substantial share of the revenue generated from messaging services, leaving MNOs with only a minimal portion. This restricted participation significantly reduces potential earnings for operators and limits their ability to influence pricing models, offer customized services, or secure a competitive revenue share within the messaging ecosystem the present disclosure overcomes the above stated issues by providing a message architecture divided into multiple microservices that enable the enterprises in effectively managing and handling SMS subscriptions and also provides options for transmitting bulk group messaging with multilingual messaging facility.

[0235] While considerable emphasis has been placed herein on the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiments of the disclosure will be apparent to those skilled in the art from thedisclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be implemented merely as illustrative of the disclosure and not as a limitation.ADVANTAGES OF THE PRESENT DISCLOSURE

[0236] The present disclosure offers a highly scalable, reliable, highly available and manageable Messaging as a Service (MaaS) architecture platform that manages both message accumulation and delivery, eliminating the need for third-party aggregation microservices.

[0237] The present disclosure provides a comprehensive solution that supports both postpaid and prepaid types of bulk messaging services for Distributed Ledger Technology (DLT) approved enterprises.

[0238] The present disclosure provides smart scrubbing features that enhance regulatory message compliance and delivery accuracy by filtering and aligning SMS with pre-approved DLT templates. This reduces the risk of regulatory violations and improves customer experience.

[0239] The present disclosure provides the MaaS platform designed with microservice architecture and multiple components to handle different services. The multiple components provide flexible and efficient services, enabling seamless integration and scalability.

[0240] The present disclosure provides instant message delivery to end-users or customers, ensuring that messages are transmitted in real-time, thereby significantly enhancing enterprise communication efficiency.

[0241] The present disclosure provides a cloud-native platform with multiple connectivity and interface options, enabling enterprises to integrate seamlessly with various channels.

[0242] The present disclosure enables enterprises to send group messages,facilitating effective business communication strategies.

[0243] The present disclosure provides user-controlled message delivery, allowing enterprises to customize their messaging experience according to specific needs.

[0244] The present disclosure provides a dynamic and multilingual messaging solution, ensuring that businesses can engage with diverse customers.

[0245] The present disclosure provides sending SMS / Email based notifications related subscriptions to Enterprises with the option of multilingual notifications.

[0246] The present disclosure provides an independent microservice designed to operate asynchronously via service APIs, allowing scalability, fault isolation, and independent deployment.

Claims

We claim:

1. A method (600) for providing scalable messaging services in a distributed computing environment, the method (600) comprising:receiving (602), by a traffic management microservice (208), one or more message transmission requests from one or more user equipments (UEs) (104);allocating (604), by the traffic management microservice (208), the one or more message transmission requests across a plurality of aggregation microservices based on one or more parameters;extracting and verifying (606), by each aggregation microservice (216), user and message information associated with the message transmission requests using data obtained from a provisioning microservice;upon verification, determining (608), by a resource management microservice (214), whether transmission of a message is authorized based on one or more predefined rules;performing (610), by each aggregation microservice (216), validation of each message based on one or more pre-approved templates; andtransmitting, by a distribution microservice (218), the validated message to one or more destination devices through one or more communication networks.

2. The method (500) as claimed in claim 1, wherein each microservice is configured to operate as an independent and containerized service communicating through one or more application programming interfaces (APIs), wherein the one or more parameters comprise, but not limited to, workload, message priority, or network conditions, wherein the one or more predefined rules comprise, but not limited to, at least one of balance availability and compatibility check, and wherein the messaging services comprise, but not limited to, at least one of short messaging service (SMS),electronic mail (email), multimedia message (MMS), rich communication service message (RCS), an instant message, promotional messages, transactional messages, and service messages.

3. The method (500) as claimed in claim 1, wherein the step of verifying the extracted information of a user (102) comprises:accessing, by each aggregation microservice (216), subscription details corresponding to the user (102) from a database (220), wherein the subscription details comprise one or more of a subscription level, a service duration, subscription credentials, a subscription type and a subscription status;matching, by each aggregation microservice (216), the accessed subscription details with the extracted information of the user (102) to determine whether the subscription status is an active status or an inactive status; andupon determining the subscription status is the active status, exchanging, by each aggregation microservice (216), the extracted information with the resource management microservice (214) for authorization.

4. The method (500) as claimed in claim 2, wherein the step of the compatibility check comprises:accessing, by each aggregation microservice (216), one or more preapproved messaging templates from the database;comparing, by each aggregation microservice (216), each of the one or more message transmission requests with the one or more accessed preapproved messaging templates; andupon detecting each of the one or more message transmission requests matches with the one or more accessed pre-approved messaging templates, marking, by each aggregation microservice (216), a corresponding message transmission request as a compatible request, andwherein, upon detecting each of the one or more message transmission requests that does not match with the one or more accessed pre-approved messaging templates, rejecting, by each aggregation microservice (216), the transfer of the message, wherein the message comprises at least one of promotional messages, transactional messages, and service messages.

5. The method (500) as claimed in claim 1, comprising: generating and transmitting, by a notification microservice (212), one or more notifications associated with at least one subscription activity, system alerts, quota usage to the user or an enterprise system.

6. The method (500) as claimed in claim 1, comprising:performing, by a network management microservice (219), one or more functions corresponding to fault, configuration, accounting, performance and security (FCAPS), wherein the one or more functions comprise monitoring system faults, maintaining configuration logs, recording messaging accounting data, evaluating performance metrics and enforcing security policies across the distributed computing environment.

7. The method (500) as claimed in claim 1, comprising:managing, by the provisioning microservice (210), one or more subscription management operations, wherein the one or more subscription management operations comprise at least one of activation, deactivation, and modification of subscriptions, wherein the traffic management microservice (208) is configured to apply a machine learning model to perform one or more traffic management operations, and wherein the one or more traffic management operations comprise at least one of, but not limited to, message traffic prediction, message routing and resource allocation.

8. A system (108) for providing scalable messaging services in a distributed computing environment, the system (108) comprising:a traffic management microservice (208) configured to receive one or more message transmission requests from one or more user equipments (UEs) (104);the traffic management microservice (208) configured to allocate the one or more message transmission requests across a plurality of aggregation microservices (216) based on one or more parameters;each aggregation microservice (216) configured to extract and verify user and message information associated with the message transmission requests using data obtained from a provisioning microservice (210); upon verification, a resource management microservice (214) configured to determine whether transmission of a message is authorized based on one or more predefined rules;each aggregation microservice (216) configured to perform validation of each message based on one or more pre-approved templates; anda distribution microservice (218) configured to transmit the validated message to one or more destination devices through one or more communication networks.

9. The system (108) as claimed in claim 8, wherein each microservice is configured to operate as an independent and containerized service communicating through one or more application programming interfaces (APIs), wherein the one or more parameters comprise, but not limited to, workload, message priority, or network conditions, wherein the one or more predefined rules comprise but not limited to at least one of balance availability and compatibility check, and wherein the messaging services comprise, but not limited to, at least one of short messaging service (SMS), electronic mail (email), multimedia message (MMS), rich communication service message (RCS), an instant message, promotional messages, transactional messages, and service messages.

10. The system (108) as claimed in claim 8, wherein the step of verifying the extracted information of a user (102) comprises:each aggregation microservice (216) configured to:access subscription details corresponding to the user (102) from a database (220), wherein the subscription details comprise one or more of a subscription level, a service duration, subscription credentials, a subscription type and a subscription status; match the accessed subscription details with the extracted information of the user to determine whether the subscription status is an active status or an inactive status; andupon determining the subscription status is the active status, exchange the extracted information with the resource management microservice (214) for authorization.

11. The system (108) as claimed in claim 10, wherein the step of the compatibility check comprises:each aggregation microservice (216) configured to:access one or more pre-approved messaging templates from the database (220);compare each of the one or more message transmission requests with the one or more accessed pre-approved messaging templates; andupon detecting each of the one or more message transmission requests matches with the one or more accessed pre-approved messaging templates, mark a corresponding message transmission request as a compatible request, wherein, upon detecting each of the one or more message transmission requests that do not match with the one or more accessed pre-approved messaging templates, each aggregation microservice (216) is configured to reject the transfer of the message, and wherein the message comprises, but not limited to,at least one of promotional messages, transactional messages, and service messages; andperform the validation of each compatible request to ensure the message to be sent adheres to regularity and organizational policies.

12. The system (108) as claimed in claim 8, comprising:a notification microservice (212) configured to generate and transmit one or more notifications associated with at least one subscription activity, system alerts, quota usage to the user (102) or an enterprise system.

13. The system (108) as claimed in claim 8, comprising:a network management microservice (219) configured to perform one or more functions corresponding to fault, configuration, accounting, performance and security (FCAPS), wherein the one or more functions comprise monitoring system faults, maintaining configuration logs, recording messaging accounting data, evaluating performance metrics and enforcing security policies across the distributed computing environment.

14. The system (108) as claimed in claim 8, comprising:the provisioning microservice (210) configured to manage one or more subscription management operations, wherein the one or more subscription management operations comprise at least one of activation, deactivation, and modification of subscriptions, and wherein the traffic management microservice (208) is configured to apply a machine learning model to perform one or more traffic management operations, wherein the one or more traffic management operations comprise at least one of message traffic prediction, message routing and resource allocation.

15. A user equipment (UE) (104) communicatively coupled with a system (108), the coupling comprises steps of:receiving, by the system (108), a connection request from the UE (104);sending, by the system (108), an acknowledgment of the connection request to the UE (104); andtransmitting, by the UE (104), at least one request to send one or more message transmission requests to the system (108), wherein the system (108) is configured to provide scalable messaging services in a distributed computing environment, as claimed in claim 8.

16. A computer program product comprising a non-transitory computer- readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform a method (500) for providing scalable messaging services in a distributed computing environment, the method (500) comprising:receiving (502), by a traffic management microservice (208), one or more message transmission requests from one or more user equipments (UEs) (104);allocating (504), by the traffic management microservice (208), the one or more message transmission requests across a plurality of aggregation microservices (216) based on one or more parameters;extracting and verifying (506), by each aggregation microservice (216), user and message information associated with the message transmission requests using data obtained from a provisioning microservice (210);upon verification, determining (508), by a resource management microservice (214), whether transmission of a message is authorized based on one or more predefined rules;performing (510), by each aggregation microservice (216), validation of each message based on one or more pre-approved templates; andtransmitting (512), by a distribution microservice (218), the validated message to one or more destination devices through one or more communication networks.

Images