Abstract: When a request for accessing a service is received, a user object may be stored in a long-term data store, as well as in a short-term cache. The cache may be divided into a regular cache that stores full versions of the user objects, and a surrogate cache that stores compact versions of the user object. The compact version of the user object may include a field that is derived from the full user object indicating whether a subsequent request for access to a particular service should be granted. After access is granted/denied based on this value in the compact user object, the system can process an update to the full user object offline. This surrogate cache structure may be used to rapidly approve/deny requests, decoupling this procedure from the processing involved with a full user object.

Abstract: When a request for accessing a service is received, a user object may be stored in a long-term data store, as well as in a short-term cache. The cache may be divided into a regular cache that stores full versions of the user objects, and a surrogate cache that stores compact versions of the user object. The compact version of the user object may include a field that is derived from the full user object indicating whether a subsequent request for access to a particular service should be granted. After access is granted/denied based on this value in the compact user object, the system can process an update to the full user object offline. This surrogate cache structure may be used to rapidly approve/deny requests, decoupling this procedure from the processing involved with a full user object.

Abstract: Techniques for stitching application programming interfaces (APIs) to communicate between applications are disclosed. Stitching APIs includes transferring data obtained using an API corresponding to a source application and an API corresponding to a destination. A system obtains a mapping file that maps data objects maintained by the source application to data objects maintained by the destination application. When the system receives a data transfer request, the system: (a) identifies the source application and the destination application, (b) identifies the mapping between objects maintained by the source application and objects maintained by the destination application, and (c) identifies the API calls for the source application and the destination application for performing the data transfer. Based on the mapping, the system invokes API calls to a source application and a destination application to transmit the data.

Abstract: Techniques for stitching application APIs to communicate between applications are disclosed. Stitching APIs includes transferring data obtained using an API corresponding to a source application and an API corresponding to a destination. A system obtains a mapping file that maps data objects maintained by the source application to data objects maintained by the destination application. When the system receives a data transfer request, the system: (a) identifies the source application and the destination application, (b) identifies the mapping between objects maintained by the source application and objects maintained by the destination application, and (c) identifies the API calls for the source application and the destination application for performing the data transfer. Based on the mapping, the system invokes API calls to a source application and a destination application to transmit the data.

Abstract: When a request for accessing a service is received, a user object may be stored in a long-term data store, as well as in a short-term cache. The cache may be divided into a regular cache that stores full versions of the user objects, and a surrogate cache that stores compact versions of the user object. The compact version of the user object may include a field that is derived from the full user object indicating whether a subsequent request for access to a particular service should be granted. After access is granted/denied based on this value in the compact user object, the system can process an update to the full user object offline. This surrogate cache structure may be used to rapidly approve/deny requests, decoupling this procedure from the processing involved with a full user object.

Abstract: An example method for lockless communications network resource quota sharing occurs at a first charging node of a distributed charging system comprising multiple charging nodes. The example method comprises: receiving, from a requesting entity, a first communications network resource quota request for requesting a first resource amount from the shared resources plan; without confirming that the shared resources plan has enough available resources to allot the first resource amount, providing, to the requesting entity, a first communications network resource quota for the first member, wherein the first communications network resource quota indicates a second resource amount less than the first resource amount and/or wherein the first communications network resource quota is associated with a validity time indicating when the first communications network resource quota expires; and sending, to a second charging node, a first resource reservation request for reserving resources of the shared resources plan.

Abstract: When a request for accessing a service is received, a user object may be stored in a long-term data store, as well as in a short-term cache. The cache may be divided into a regular cache that stores full versions of the user objects, and a surrogate cache that stores compact versions of the user object. The compact version of the user object may include a field that is derived from the full user object indicating whether a subsequent request for access to a particular service should be granted. After access is granted/denied based on this value in the compact user object, the system can process an update to the full user object offline. This surrogate cache structure may be used to rapidly approve/deny requests, decoupling this procedure from the processing involved with a full user object.

Abstract: Methods, systems, and computer readable media for request response processing. A method includes establishing a request topic and a response topic for distributing messages between clients and services executing on a distributed computing system. The method includes posting, in the request topic, request messages from the clients, each request message including a unique client identifier, such that the services consume the request messages from the request topic. The method includes posting, in the response topic, response messages from the services responsive to the request messages. The services post the response messages to response partitions of the response topic using the unique client identifiers. The clients consume the response messages using the unique client identifiers to ensure that each client consumes a respective responsive message responsive to a respective request message from the client.

Abstract: Methods, systems, and computer readable media for request response processing. A method includes establishing a request topic and a response topic for distributing messages between clients and services executing on a distributed computing system. The method includes posting, in the request topic, request messages from the clients, each request message including a unique client identifier, such that the services consume the request messages from the request topic. The method includes posting, in the response topic, response messages from the services responsive to the request messages. The services post the response messages to response partitions of the response topic using the unique client identifiers. The clients consume the response messages using the unique client identifiers to ensure that each client consumes a respective responsive message responsive to a respective request message from the client.

Abstract: An example method for lockless communications network resource quota sharing occurs at a first charging node of a distributed charging system comprising multiple charging nodes. The example method comprises: receiving, from a requesting entity, a first communications network resource quota request for requesting a first resource amount from the shared resources plan; without confirming that the shared resources plan has enough available resources to allot the first resource amount, providing, to the requesting entity, a first communications network resource quota for the first member, wherein the first communications network resource quota indicates a second resource amount less than the first resource amount and/or wherein the first communications network resource quota is associated with a validity time indicating when the first communications network resource quota expires; and sending, to a second charging node, a first resource reservation request for reserving resources of the shared resources plan.

Abstract: An Online Charging System (“OCS”) that processes charging on a telecommunications network receives an indication of usage of a telecommunications service by a subscriber. In response to the indication, the OCS determines a configured offering for the service, where the configured offering includes a time period, and a credit and/or debit. The OCS determines if the usage of the service is a first usage within the time period, and when the usage is the first usage, applies the credit and/or debit. The OCS then determines a charge for the usage based on credit and/or debit.

Abstract: An Online Charging System (“OCS”) that processes charging on a telecommunications network receives an indication of usage of a telecommunications service by a subscriber. In response to the indication, the OCS determines a configured offering for the service, where the configured offering includes a time period, and a credit and/or debit. The OCS determines if the usage of the service is a first usage within the time period, and when the usage is the first usage, applies the credit and/or debit. The OCS then determines a charge for the usage based on credit and/or debit.