Asynchronous Slack-jira Integration Via Queue “Middleware”: Comparison of “Cloud Computing” Solutions

Julia Cabral Diniz Braz; Marcos Jardel Henriques

DOI: 10.22167/2675-6528-202603094

Article derived from a Course Conclusion Work (TCC), with content based on the student’s original work and adapted to the editorial format of the E&S Magazine with the support of the ResumeAI tool, an artificial intelligence solution developed by Instituto Pecege for textual synthesis and organization.

Summary

The latency and interoperability between distributed corporate systems constituted the problem investigated, motivated by the costs and fragilities of manual integrations between collaboration and project management platforms. An asynchronous integration “middleware” between Slack and Jira was developed and validated, with the objective of reducing the perceived user response time and ensuring system stability under load. The methodology consisted of building an event-driven software architecture in Python, using the “producer-consumer” and “adapter” patterns to isolate the user interface from “backend” processing. The solution evolved into a cloud-agnostic architecture, based on “serverless” functions, and was subjected to stress tests in local, real network, and production environments on two clouds. The architecture reduced user waiting time from a synchronous estimate of 2,000 milliseconds to a local average of 8.96 milliseconds. Under a load of 50 simultaneous requests, both cloud providers proved viable: Amazon Web Services registered lower average latency in the reception layer (951.35 ms) and double the throughput, while Microsoft Azure executed background processing with a median of 113 ms. The application of “optimistic UI” ensured fluidity of use, and load leveling by queues eliminated the need for infrastructure over-provisioning. The “middleware” consolidated itself as a scalable, resilient, and protected corporate reference model against technological lock-in.

Keywords: Event-driven architecture; Temporal decoupling; Operational efficiency; Information technology service management; Systems interoperability.

1. Introduction

In the environment of a technology company, the integration between communication and project management tools has proven essential to ensure productivity, traceability, and operational efficiency. Slack, widely used as a corporate messaging platform for agile team communication, and Jira, a recognized project management system, hold a central position in software development and management routines, activities whose coordination depends directly on the quality of information flows that cross product boundaries (Sommerville, 2019).

Despite the importance, latency and interoperability between distributed corporate systems constitute a recurring problem. Manual integrations between collaboration platforms and project management tools are often burdensome and fragile. Native integrations between these platforms, specifically between Slack and Jira, present significant limitations and entail additional costs, a fragility that the corporate integration literature attributes to the absence of a dedicated message intermediary between applications (Hohpe and Woolf, 2012).

In a technology company analyzed, for example, Slack messages were transferred to a spreadsheet in Google Sheets, and a script was responsible for creating Jira cards. Although functional, this approach presented limitations in scalability, security, and maintenance, deficiencies characteristic of point-to-point integrations built without a decoupling layer (Newman, 2015).

Given this scenario, the development of an event-oriented middleware, based on message queue systems, was proposed. This solution aims to mediate and manage communication between Slack and Jira efficiently, securely, and scalably, abstracting the complexity of integrating application programming interfaces. The objective is to promote an automated and monitorable data flow between the systems, ensuring greater operational fluidity and reliability.

In addition to solving a practical problem, this project contributes to the enhancement of skills in systems integration, event-driven architectures, message queues, and cloud computing, topics of great relevance in contemporary software engineering. Recent literature highlights the importance of comparative analyses between cloud providers to support technological choices (Al-Sayyed et al., 2019; Kaushik et al., 2021; Palumbo et al., 2021; Madhuri and Sowjanya, 2016; Gupta et al., 2021). In this context, the comparison between the managed queue services of the two clouds, proposed in this work, not only supports the most adequate architectural choice but also contributes to the advancement of knowledge about cloud messaging solutions from distinct perspectives of cost, reliability, and performance.

The relevance of the study lies, therefore, in its capacity to offer a robust solution for a common problem in corporate environments, while simultaneously deepening the academic discussion on best practices in distributed systems integration and cloud computing. The general objective of this work was to develop and validate an asynchronous integration “middleware” between Slack and Jira, capable of reducing the perceived response time by the user and ensuring system stability under load.

2. Material and Methods

The research was characterized as applied and of a technological nature, focused on the development and validation of an asynchronous integration “middleware” between Slack and Jira. The methodology adopted an event-oriented software architecture (Gil, 2002), aiming to reduce the perceived response time by the user and ensure system stability under load.

The development occurred in four stages: implementation of decoupled microservices in Python; application of optimistic UI (“optimistic UI”); execution of stress tests to measure latency and throughput; and comparison of system performance and portability between local processing and public cloud messaging infrastructures.

The architecture was based on the decomposition into independent microservices, following the Producer-Consumer pattern (Newman, 2015). The “producer” was designed for receiving HTTP requests, and the “worker” was refactored for a “serverless” approach and event-driven functions. This segregation of responsibilities avoided bottlenecks (Hohpe and Woolf, 2012). For interoperability and provider independence, the “adapter” pattern was applied (Gamma et al., 1995), unifying communication methods between local queues and cloud-managed queue services. The use of queues for “queue-based load leveling” avoided resource over-provisioning (Armbrust et al., 2010).

The solution was implemented in distinct modules, with reception and processing layers. The reception layer used frameworks and libraries to absorb user interactivities and transfer heavy executions to the message queue, returning an immediate success code to bypass Slack’s timeout (Slack Technologies, 2025). The processing layer consumed messages from the queue and executed transactions via Jira’s programming interface (Atlassian, 2025).

Infrastructure abstraction ensured application agnosticism to the deployment environment. Channel mapping evolved to “serverless” functions and persistence in cloud-managed NoSQL services. Native entry points integrated the “serverless” solution into providers like AWS and Azure. The graphical interface for system management was developed in HTML5 and Bootstrap, providing a visual dashboard for linking channel configurations. The system logic was documented by pseudocodes, and functional validation by screenshots, recording the effectiveness of the user interface.

The architecture validation was performed through stress tests, using a Python automation script with the `concurrent.futures` library. Three experimental scenarios were defined for data collection. In the first, a baseline scenario, one hundred parallel requests were fired across ten threads, with the reception layer and the worker operating on the same physical machine, eliminating external network latency.

In the second scenario, a real network, one hundred requests were fired in ten execution threads through a secure HTTP tunnel, forcing the traffic to travel through the public network. The third scenario, production, executed the test on real “serverless” infrastructures, with a load of fifty simultaneous requests in ten execution threads against the instances of the two cloud providers.

The response data, including the HTTP request status and latency time in milliseconds, were extracted locally to CSV files in the first two scenarios and directly from the official cloud monitoring tools in the third. For quantitative analysis, descriptive statistics methods were applied, using the `statistics` library of the Python language, calculating the simple arithmetic mean, median, and throughput to synthesize the system’s latency behavior.

3. Results and Discussion

The results obtained demonstrated the technical viability and operational efficiency of the event-driven architecture applied to the integration of systems offered as a service. The collected data allowed for the evaluation of the solution from three distinct perspectives: computational performance, network behavior, and functional integrity. The research validated the hypothesis that an asynchronous “middleware” can mitigate latency and ensure stability in distributed systems, a common challenge in corporate environments that rely on interoperability between platforms such as Slack and Jira.

The system’s performance analysis was conducted in two distinct stages, with the purpose of isolating computational processing time from the latency imposed by the network infrastructure. In both scenarios, the stress testing protocol with one hundred simultaneous requests was used, simulating the behavior of multiple users. This approach allowed for a robust evaluation of the solution’s capacity to handle demand peaks, a critical requirement for real-time integration systems.

In the first experimental scenario, characterized as a baseline, the proposed architecture presented high efficiency in data ingestion processing. Of the one hundred requests simultaneously triggered by the “script”, a one hundred percent success rate was recorded, with no errors or timeouts occurring. The average response latency of the reception layer was 8.96 milliseconds, with a minimum time of 5.28 milliseconds and a maximum of 26.08 milliseconds. The system throughput exceeded the mark of 1,000 requests per second.

Such values indicated that queue decoupling eliminated the “backend” processing lag time and returned control to the client almost instantaneously. System stability during the load test was notable, with the latency line remaining constant, around seven milliseconds, after the first ten requests. This demonstrated that the application did not suffer performance degradation even under concurrency of multiple execution threads, validating the robustness of the asynchronous design.

In the second scenario, which simulated real conditions of remote access via secure tunnel, the average response time increased to 605.93 milliseconds. This increase was attributed to the time it takes for packets to travel across the network, known as “round trip time”, as the application’s internal processing remained unchanged. Even with the added network latency, the system preserved data integrity and processed the total load in 6.13 seconds, which validated the robustness of the solution for cloud environments.

Despite the network’s natural fluctuation, the system’s stability remained unchanged, demonstrating that, even under variable latency conditions, the application preserved service consistency without failures. This behavior is crucial to ensure a fluid and reliable user experience in integrations that depend on external network infrastructures, as is the case with distributed systems interacting with cloud services.

The comparison of the obtained results with the average response times of a traditional synchronous architecture, conservatively estimated at 2,000 milliseconds for operations on the Jira platform, added to the network latency, evidenced a substantial performance gain of the developed solution. In the baseline scenario, the asynchronous solution proved to be approximately 223 times faster from the user’s response perspective, a significant advance in operational efficiency.

In the scenario with network latency, the response of 605.93 milliseconds represented a reduction of approximately 77% in total lag time, when compared to the hypothetical sum of network latency with synchronous processing time, of approximately 2,600 milliseconds. This gain is a testament to the effectiveness of temporal decoupling and the application of optimistic user interfaces (“optimistic UI”), which minimize the user’s perception of latency (Hohpe and Woolf, 2012).

From the perspective of cloud financial management, this behavior validated the application of the load leveling pattern by queues, as described by Hohpe and Woolf (2012). The consumer component operated with linear computational capacity, regardless of request peaks in the reception layer, which suggested compatibility with function-based computing models and avoided resource waste due to over-provisioning. This elasticity mechanism is one of the main economic advantages of cloud computing, as identified by Armbrust et al. (2010).

To validate the efficiency and behavior of the agnostic architecture in a real production environment, a comparative performance analysis was conducted between the “serverless” instances of the two cloud providers. The tests focused on measuring the latency of critical system operations, with the instances operating on on-demand consumption plans, under a stress load of fifty simultaneous requests distributed across ten execution threads.

The HTTP reception layer response time metrics extracted from the official monitoring tools of each platform revealed notable differences. The total test time was 4.84 seconds on Amazon Web Services and 10.57 seconds on Microsoft Azure, indicating a higher overall reception speed on AWS. AWS’s overall throughput was 10.33 requests per second, double that of Azure, which registered 4.73 requests per second.

The average latency on AWS was 951.35 milliseconds, while on Azure it was 2,011.73 milliseconds, demonstrating a lower perceived user lag time on AWS. The median latency also favored AWS, with 319.33 milliseconds, compared to 1,151.65 milliseconds on Azure, suggesting greater stability in AWS’s response. The minimum latency time was 288.06 milliseconds on AWS and 644.04 milliseconds on Azure, indicating a lower latency floor on AWS.

Both clouds registered “cold start” peaks in the initial interactions, with AWS reaching values around 3,400 milliseconds and Azure exceeding the 5,000-millisecond mark in maximum time. AWS’s infrastructure adapted more quickly to the load and stabilized, after about ten requests, in a baseline range close to 300 milliseconds, with very low delay variation (“jitter”). Microsoft Azure, even after the initial warm-up, exhibited a more erratic curve, with recurring fluctuations between 644 milliseconds and 4,672 milliseconds throughout the rest of the test.

This variability converges with what Palumbo et al. (2021) observed when characterizing the latency between cloud and user in the two providers, and with the advantage of AWS in web service response metrics reported by Al-Sayyed et al. (2019) and Gupta et al. (2021). The interquartile concentration of AWS proved to be considerably lower and denser around the median of 319.33 milliseconds, which confirmed the managed gateway service’s ability to absorb massive requests predictably and to isolate the user interface from processing delays.

The interquartile range of Azure, about nine times larger, translated into a less predictable user experience, a result aligned with the performance differences between providers documented by Kaushik et al. (2021). These findings highlight the importance of a detailed analysis of the performance characteristics of each cloud provider, especially in high-load scenarios and for applications that require low latency in the reception layer.

The evaluation of the proposed architecture’s efficiency was not limited to the HTTP input layer. Detailed analysis of raw monitoring logs revealed substantially distinct queue transit between providers and depicted the actual computational time required by consumer functions to process data in the background. This end-to-end behavior is fundamental to understanding the fluidity of the complete transaction.

From the internal processing perspective, Microsoft Azure demonstrated markedly optimized behavior and surpassed the performance of its own HTTP layer. In the fifty successfully executed samples, a minimum time of 10.43 milliseconds and a peak of 449.11 milliseconds were recorded, with a median of 113 milliseconds. This efficiency stemmed from the consumption plan’s asynchronous trigger model, aided by a native scale control component that, upon detecting load spikes, performed very frequent queries to the storage queue (Microsoft, 2025).

The practical result was a transition from the reception layer to the consumer function in about 113 milliseconds, which made the asynchronous latency imperceptible for the creation of the call in Jira. In contrast, Amazon Web Services, which showed short and predictable HTTP reception times, evidenced a considerable bottleneck in asynchronous resolution. In the same fifty successful events, the shortest internal processing time was 1,078.81 milliseconds and the highest peak, influenced by the “cold start” of the Python language, reached 4,106.20 milliseconds, with a median of 2,359.94 milliseconds.

This latency in AWS stemmed from the on-demand model’s mechanics: queue nodes associated with function triggers operated under a batch window and query control regime, such that the cloud deliberately waited for batches of messages to accumulate before instantiating a warm container to execute the code (Amazon Web Services [AWS], 2025). This was a native provider strategy that sacrificed latency in favor of cost reduction for background tasks, highlighting a technical trade-off between performance and cost.

The experimental data thus proved the underlying thesis of the multi-cloud architecture. Microsoft Azure showed greater initial slowness in web calls, while AWS dominated HTTP processing speed at the interface layer. For distributed background queue processes, however, AWS imposed a cost-oriented infrastructure bottleneck, which generated asynchronous delays with a median of 2,359.94 milliseconds and peaks exceeding four seconds.

In contrast, Microsoft’s architecture processed event queues in approximately 113 milliseconds, with no apparent temporal constraint. The joint reading of the two excerpts nuanced the findings of Madhuri and Sowjanya (2016), who compared providers primarily by their web services layer. The inversion of advantage between the two layers indicated that the preference between providers for “serverless” solutions depended on how the organization designed its microservices and the priority non-functional requirements, i.e., perceived latency at the interface, with AWS having an advantage, or end-to-end transaction fluidity, with Azure having an advantage.

Configuration and management of “middleware”

Before the execution of the workflows, the application management module was validated. The graphical interface was developed in HTML5 with the Bootstrap library, allowing the system to be parameterized visually and eliminating the need for direct alteration of the source code for mapping adjustments. This approach simplified system management and maintenance, making it accessible to users without in-depth technical knowledge of programming.

The dashboard enabled dynamic mapping between Slack source channels and Jira destination projects. The interface also provided debugging mechanisms by displaying the validation of mandatory fields for registration, which facilitated the identification of inconsistencies in the input data before test execution. This functionality is crucial for preventing errors and ensuring the integrity of data that transits between platforms, increasing the reliability of the integration.

Functional validation and visual evidence

In addition to quantitative analysis, the functional validation of the integration between platforms was documented through screenshots, which proved the effectiveness of the user interface in all stages of the workflow. This visual validation is essential to demonstrate the usability and adherence of the solution to the operational needs of the users.

Initially, the data input mechanism was validated. When the user triggered the initial command, the application correctly rendered the modal form window. This step confirmed that the reception layer received the user’s trigger and returned the data structure corresponding to the fillable fields without noticeable latency, ensuring a fast and responsive initial interaction.

Subsequently, the implemented instant feedback mechanism was demonstrated. At the exact moment of form submission, the system returned a provisional confirmation message. This behavior, characteristic of optimistic UIs (“optimistic UI”), assured the user that the request had been successfully received and eliminated uncertainty during the asynchronous processing period, improving the overall user experience.

The dynamic update of the interface was presented. After processing by the “worker”, the provisional message was automatically replaced by an interactive card with the task identifier and action buttons. The correct rendering of these elements confirmed the system’s ability to update the conversation state in real time, providing immediate and relevant feedback to the user on the request status.

The transaction’s completion in the destination system was verified. The task was correctly created on the Jira platform and preserved the fidelity of all information entered in the initial form. This ensured that the data was transferred with accuracy and integrity, a fundamental aspect for the traceability and reliability of project management processes.

In summary, the development of the asynchronous integration “middleware” between Slack and Jira proved to be an effective strategy for reducing user-perceived latency and ensuring system stability under load. The event-driven architecture, with temporal decoupling and the use of message queues, overcame the limitations of traditional synchronous integrations. The comparative analysis between cloud providers revealed that, although both are viable, the ideal choice depends on the specific latency requirements at each system layer, consolidating a scalable, resilient, and cloud-agnostic corporate reference model.

4. Conclusion

This study aimed to develop and validate an asynchronous integration middleware between Slack and Jira, seeking to reduce the perceived response time by the user and ensure system stability under load. It was found that the event-driven architecture, with temporal decoupling and the use of message queues, significantly mitigated the latency issues inherent in distributed systems. Tests demonstrated an expressive reduction in user waiting time, from a synchronous estimate of 2,000 milliseconds to a local average of 8.96 milliseconds. Under a load of fifty simultaneous requests, the solution maintained stability, with Amazon Web Services showing lower average latency in the reception layer and double the throughput, while Microsoft Azure excelled in efficient background processing, with a median of 113 milliseconds. The application of optimistic interfaces ensured fluidity of use, and load leveling by queues eliminated the need for infrastructure over-provisioning. This approach consolidated a scalable, resilient, and technologically vendor lock-in protected corporate reference model, offering a robust solution for workflow automation in corporate environments.

Despite performance and stability gains, it was observed that the “cold start” phenomenon impacted the initial interactions in both cloud providers, resulting in initial latency spikes. Additionally, Amazon Web Services’ queue processing strategy, which prioritizes cost reduction through message batch accumulation, introduced higher asynchronous latencies in background processing, highlighting a technical trade-off between performance and cost. These findings suggest that the choice of the ideal provider for serverless solutions depends on the prioritized non-functional requirements of each organization, whether it is perceived interface latency or end-to-end transaction fluidity. For future studies, it is recommended to deepen the analysis of hybrid or multicloud strategies that optimize performance in both layers, exploring the combination of providers to mitigate the observed limitations and maximize operational and financial efficiency in high-demand scenarios.

Bibliographic References

Al-Sayyed, R.M.H.; Hijawi, W.A.; Bashiti, A.M.; Aljarah, I.; Obeid, N.; Adwan, O.Y. 2019. An investigation of Microsoft Azure and Amazon Web Services from users’ perspectives. International Journal of Emerging Technologies in Learning 14(10): 110-116.

Amazon Web Services [AWS]. 2025. Amazon Simple Queue Service Developer Guide. Disponível em: <https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/>. Acesso em: 26 out. 2025.

Armbrust, M.; Fox, A.; Griffith, R.; Joseph, A.D.; Katz, R.; Konwinski, A.; Lee, G.; Patterson, D.; Rabkin, A.; Stoica, I.; Zaharia, M. 2010. A view of cloud computing. Communications of the ACM 53(4): 50-58.

Atlassian. 2025. Jira Cloud Platform REST API. Disponível em: <https://developer.atlassian.com/cloud/jira/platform/rest/>. Acesso em: 26 out. 2025.

Gamma, E.; Helm, R.; Johnson, R.; Vlissides, J. 1995. Design Patterns: Elements of reusable object-oriented software. Addison-Wesley, Boston, MA, EUA.

Gil, A.C. 2002. Como Elaborar Projetos de Pesquisa. 4.ed. Atlas, São Paulo, SP, Brasil.

Gupta, B.; Mittal, P.; Mufti, T. 2021. A review on Amazon Web Service (AWS), Microsoft Azure and Google Cloud Platform (GCP) services. In: International Conference on ICT for Digital, Smart and Sustainable Development, 2020, Nova Délhi, Índia. Anais… European Alliance for Innovation, Gante, Bélgica.

Hohpe, G.; Woolf, B. 2012. Enterprise Integration Patterns: Designing, building, and deploying messaging solutions. Addison-Wesley, Boston, MA, EUA.

Kaushik, P.; Rao, A.M.; Singh, D.P.; Vashisht, S.; Gupta, S. 2021. Cloud computing and comparison based on service and performance between Amazon AWS, Microsoft Azure, and Google Cloud. In: International Conference on Technological Advancements and Innovations, 2021, Tashkent, Uzbequistão. Anais… Institute of Electrical and Electronics Engineers, Piscataway, NJ, EUA. p. 268-273.

Madhuri, T.; Sowjanya, P. 2016. Microsoft Azure v/s Amazon AWS cloud services: a comparative study. International Journal of Innovative Research in Science, Engineering and Technology 5(3): 3904-3908.

Microsoft. 2025. Azure Queue Storage Documentation. Disponível em: <https://learn.microsoft.com/azure/storage/queues/>. Acesso em: 26 out. 2025.

Newman, S. 2015. Building Microservices: Designing fine-grained systems. O’Reilly Media, Sebastopol, CA, EUA.

Palumbo, F.; Aceto, G.; Botta, A.; Ciuonzo, D.; Persico, V.; Pescapé, A. 2021. Characterization and analysis of cloud-to-user latency: the case of Azure and AWS. Computer Networks 186: 107693.

Slack Technologies. 2025. Slack Web API Documentation. Disponível em: <https://api.slack.com/web>. Acesso em: 26 out. 2025.

Sommerville, I. 2019. Engineering Software Products: An introduction to modern software engineering. Pearson, New York, NY, EUA.

Article originating from the Final Course Work of the Specialization in Software Engineering of the MBA USP/Esalq

To learn more about the course, click here and access the MBX Academy platform