Backend Server Restructuring for Interoperability, Scalability, and Security through Well-Designed APIs

doi:10.22167/2675-6528-202601350

October 19, 2026

Backend Server Restructuring for Interoperability, Scalability, and Security through Well-Designed APIs

Backend Server Restructuring for Interoperability, Scalability, and Security Through Well-Designed APIs

Rariman Lara Silva da Rocha; Vinicius Santos Andrade

DOI: 10.22167/2675-6528-202601350

Article prepared by the ResumeAI tool, an artificial intelligence solution developed by the Pecege Institute focused on synthesis and writing.

Summary

The present study proposed and implemented an API-oriented backend architecture for telemetry systems of equipment, with the objective of improving performance, scalability, and data organization. Initially, an analysis was carried out on the limitations of approaches based exclusively on analytical databases for real-time applications, which evidenced problems of latency and coupling with the front-end. From this diagnosis, a hybrid architecture was developed, which separated analytical and transactional data, and a data materialization process was introduced to consolidate telemetry information into a model optimized for querying. In parallel, a REST API was built in the Backend for Frontend (BFF) standard, including the definition of routes, authentication (OAuth2 and JWT), versioning, and automated documentation (Swagger/OpenAPI). Business rules were elaborated for the management of users, devices, and operational flows, and comprehensive unit tests were implemented for validation of authentication, HTTP method idempotency, and pagination. The results demonstrated a significant reduction in query response time, an increase in operation reliability, and the API’s compliance with best practices for design and security. The approach provided a structured basis for decision-making and system evolution, optimizing information consumption by clients and the efficient use of computational resources, contributing to the sustainability and trust of the digital ecosystem.

Keywords: Authentication; Confidence; Performance; Data materialization; Telemetry.

1. Introduction

The contemporary technological landscape is marked by the proliferation of distributed systems and the expansion of the Internet of Things (IoT), driving the massive generation and consumption of data. In this context, equipment telemetry plays a fundamental role, enabling remote monitoring and continuous collection of critical operational information. Thousands of modules in the field, across various industrial sectors, generate a significant volume of data, posing considerable challenges in terms of scalability, processing, and storage (Newman, 2021). To enable efficient communication and integration between devices and applications, Application Programming Interfaces (APIs) have emerged as indispensable architectural elements. The Representational State Transfer (REST) architecture, proposed by Fielding (2000), has consolidated itself as the dominant paradigm for web API design, promoting standardization, simplicity, and scalability. Literature and market practice reiterate the importance of APIs as the foundation for open digital ecosystems, facilitating interaction between applications (Newman, 2015; Fowler, 2019). The demand for robust and responsive telemetry systems therefore requires a backend infrastructure that manages large volumes of data in an agile and secure manner.

Despite the ubiquity of APIs, the design of well-structured and secure interfaces remains a complex challenge. An API, as defined by the Institute of Electrical and Electronic Engineers (IEEE, 2021), is a software interface that establishes a set of functions and protocols for communication between system components, promoting interoperability and modularization. The REST architectural style, in turn, is based on the manipulation of resources identified by URLs and the use of standardized operations, such as HTTP methods, emphasizing statelessness and the separation between client and server (Fielding, 2000). This approach contrasts with models such as Remote Procedure Calls (RPC) (Birrel and Nelson, 1984) and SOAP (World Wide Web Consortium, 2007). To ensure sustainability and usability, Zimmermann et al. (2017) highlight the need for governance practices, versioning, robust authentication (OAuth2 and JWT), and automated documentation (Swagger/OpenAPI). Madden (2020) complements this by emphasizing that security must be intrinsic to API design, including rigorous data validation and continuous monitoring.

The choice of backend architecture is crucial for the performance and scalability of telemetry systems. Monolithic architectures, where all functionalities are implemented as a single unit, can present limitations in high-demand environments (Newman, 2020). In contrast, microservices-based architectures, which divide the system into autonomous services that communicate via APIs, offer greater flexibility and scalability (Newman, 2021). In the context of telemetry, data persistence often involves Online Analytical Processing (OLAP) databases, optimized for large volumes and complex analytical queries. However, the exclusive use of OLAP databases to serve real-time applications, which demand fast transactional responses, can result in latency issues and excessive coupling with presentation layers, impacting user experience. To mitigate these challenges, data materialization emerges as an effective strategy, consolidating telemetry information into a query-optimized model, separating analytical from operational loads. Additionally, the Backend for Frontend (BFF) pattern allows the API to be adapted to specific client needs, optimizing information consumption and resource utilization.

The analysis of backend architectures for telemetry systems frequently reveals latency bottlenecks in real-time queries and excessive coupling with the front-end, due to the exclusive use of analytical databases for operational demands. Such limitations compromise performance, scalability, and data organization, in addition to introducing security risks due to the absence of good API design practices. The present study is justified by the need to develop a solution that overcomes these deficiencies, providing a more efficient and reliable environment. Thus, the main objective of this work is to propose and implement an API-oriented backend architecture for equipment telemetry systems, aiming to improve performance, scalability, data organization, and operational security.

2. Material and Methods

The research adopted an applied methodology, with a qualitative and descriptive approach, focused on the analysis and implementation of good practices in the design and governance of Application Programming Interfaces (APIs). This study was conceived as a practical case, aiming at the restructuring of a backend server for equipment telemetry systems. The central objective was to investigate and apply guidelines to modernize the integration between field devices and web systems, seeking to improve performance, scalability, and security. The applied nature of the research allowed for the practical validation of the proposed solutions in a real operational environment, contributing to the resolution of a specific technological problem.

The study was conducted in a large company, a manufacturer of medical equipment, located in the state of Rio Grande do Sul, Brazil. The research was developed specifically in the area of Project Engineering and Research and Development (R&D), the department responsible for the complete product development cycle, including mechanical, hardware, and software aspects. The period of the work corresponded to the year 2026, according to the presentation date of the Course Conclusion Work. The unit of analysis consisted of the existing backend architecture and the proposed restructuring for equipment telemetry systems, aiming to improve their interoperability, scalability, and security.

Given the nature of the case study, there was no population or sample defined in the traditional statistical sense. The research focused on the backend architecture of an existing telemetry system at the company, which managed data from thousands of equipment modules in the field. The unit of analysis was the backend system itself, with a focus on its performance limitations and coupling with the front-end. The selection criteria for the study’s scope were the deficiencies identified in the legacy architecture, which justified the need for an API-oriented restructuring to optimize performance and security.

Data collection began with a comprehensive literature review, conducted in the Google Scholar and ACM Digital Library databases. Keywords such as “API design”, “API architecture”, “RESTful APIs”, “microservices architecture”, “API governance”, “API versioning”, and “API security” were used to identify relevant publications. The selection of articles for in-depth reading was based on relevance and adherence to the theme of API architecture and design. Additionally, reference books and dissertations in the field were consulted, including Fielding’s (2000) dissertation on REST architecture and Richardson et al.’s (2007) book on the implementation of RESTful services, which underpinned the adopted concepts and guidelines.

Following the literature review, a technical diagnosis of the existing backend environment at the company was carried out. This diagnosis aimed to identify the current server structure, the integration patterns employed, interoperability limitations, and critical failure points related to the scalability and security of communications between devices and systems. Based on this analysis, a C4 diagram was developed, representing the proposed architecture for the backend restructuring. This diagram detailed the components, containers, and updated integration flows, serving as a comparative tool to highlight the expected improvements in terms of the solution’s interoperability, scalability, and security.

Based on the best practices identified in the literature and the demands of the studied environment, a new API-oriented backend architecture model was developed. The development focused on the services layer, implementing a REST API following the Backend for Frontend (BFF) standard. This stage involved the conception of endpoints and specific business rules to serve the different frontend applications. Standards for authentication, version control, and the creation of automated documentation were defined, aiming to facilitate system integration and maintenance, ensuring that the API was robust and adaptable to client needs.

The structuring of the API endpoints followed a standardized route convention, composed of a technical prefix (/api), the identification of the consuming channel (such as /web or /mobile), an explicit versioning (/v1), and segmentation by functional domain (e.g., /auth and /users). This approach was adopted to reduce coupling between clients, optimize the organization of API documentation, and allow for independent evolution of the exposed contracts. Table 1 presents detailed examples of API endpoints, illustrating the application of this convention by consuming channel, version, and functional domain, facilitating the understanding of the implemented structure.

Table 1. API endpoints examples

Endpoint	Channel	Version	Domain	Purpose
/api/web/v1/auth/login	Web	v1	Authentication	Perform web authentication
/api/web/v1/users/me	Web	v1	Users	Return authenticated user data on the web
/api/web/v1/devices/{id}/details/	Web	v1	Equipment	Return equipment details #id on the web
/api/web/v1/devices/locations/?page=1&page_size=5000	Web	v1	Equipment	Return last equipment location using web pagination
/api/mobile/v1/auth/login	Mobile device	v1	Authentication	Perform authentication on mobile
/api/mobile/v1/users/me	Mobile device	v1	Users	Return authenticated user data on mobile
/api/mobile/v1/devices/{id}/details/	Mobile device	v1	Equipment	Return equipment details #id on mobile
/api/mobile/v1/devices/locations/?page=1&page_size=5000	Mobile device	v1	Equipment	Return last equipment location using mobile pagination

Source: Original survey data

After the architecture implementation, a rigorous testing and validation phase was carried out, covering functional, performance, and security aspects of the API. Functional tests were designed to verify the adherence of endpoints to the Swagger/OpenAPI documentation, including mandatory fields, data types, HTTP codes, and standardized error messages. The idempotency of GET, PUT, and DELETE methods, the consistency of pagination and filters, and the robustness of authentication and authorization mechanisms based on JSON Web Tokens (JWT) were also evaluated. System validation was guided by well-defined acceptance criteria, ensuring reliability and compliance with established requirements.

Test case planning involved identifying and organizing evaluation scenarios, detailing input data, execution conditions, and expected results for each. Both positive scenarios, which verified the system’s correct behavior, and negative scenarios, focused on validating error and exception handling, were considered. The scope of testing was carefully defined to prioritize critical functionalities and components, with special attention to authentication routes, access control, and data manipulation. This approach ensured that the points with the greatest impact on the application’s security and overall functionality were exhaustively evaluated.

The tests were implemented in an automated manner using the `pytest` tool, allowing for repetitive, standardized, and consistent execution of the defined scenarios. This automation facilitated early detection of failures and continuous validation of functionalities throughout development, contributing to the system’s robustness and quality. The test cases, detailed in the appendices of the work, covered user authentication, token flow, idempotency of HTTP PUT and DELETE methods, and results pagination. The analysis of data collected during the tests was performed by comparing the results obtained before and after the restructuring, using tables and graphs to measure the impact on operational efficiency and the sustainability of the API architecture.

The analysis of test data focused on verifying the API’s compliance with functional and security requirements. For authentication, the correct validation of users, handling of invalid requests, and consistency of responses were evaluated. In the token flow, the generation, validation, renewal, and expiration of access tokens were verified, as well as the handling of misuse. The idempotency of PUT and DELETE methods was analyzed to ensure the consistency of the resource state after multiple executions. Finally, pagination was tested for navigation, control of items per request, and handling of invalid values, ensuring the predictability and coherence of the results.

This study, of a technical nature and focused on the restructuring of a software architecture, did not involve the participation of human beings or the collection of sensitive data, therefore, it did not require the application of formal ethical procedures. Regarding methodological limitations, the work focused on a specific case study, which may restrict the direct generalization of the results to other organizational contexts or telemetry systems with substantially different characteristics. However, the detailed approach and practical validation of the proposed solution offer a replicable and adaptable model for similar scenarios, contributing with a framework of best practices.

3. Results and Discussion

This section of Results and Discussions details the research findings, starting with the contextualization of principles and methods for API design, followed by the analysis of the legacy architecture, the proposition of the new architecture, and the presentation of the unit test results. The central objective was to investigate and apply API design and governance best practices to restructure a telemetry backend server, aiming to improve performance, scalability, and security. The applied methodology, qualitative and descriptive in nature, allowed for the practical validation of the solutions in a real operational environment, providing a framework of best practices for similar technological scenarios.

The understanding of Application Programming Interfaces (APIs) is fundamental for the integration of modern systems. According to the Institute of Electrical and Electronic Engineers (IEEE, 2021), an API is a software interface that establishes a set of functions, methods, and protocols, enabling communication and interoperability between different system components. This definition highlights the crucial role of APIs in modularization and in the ability of heterogeneous systems to communicate efficiently. In the current context of digital ecosystems, APIs are not just technical tools, but represent the way organizations expose their functionalities and business models, becoming strategic interfaces for developers and for the creation of new integrations (Jin et al., 2018). The quality of an API’s design, therefore, directly reflects the usability, security, and sustainability of the system that exposes it.

Different API architectural paradigms coexist, each with its particularities in terms of interaction, coupling, and complexity. The Representational State Transfer (REST) architectural style, proposed by Fielding (2000), has consolidated itself as one of the most influential models for the design of modern web APIs. The main characteristic of REST is statelessness, where each client request to the server contains all the necessary information to be understood, without the server needing to store the client’s session context between requests. This approach promotes simplicity, scalability, and separation of concerns between client and server, facilitating the independent evolution of both sides of the communication. Adherence to RESTful principles, such as the use of resources identified by URLs and standardized operations (HTTP methods), is an indicator of an API’s maturity, according to the Richardson et al. (2007) Maturity Model, which classifies APIs into levels of adherence to these principles, from remote procedure calls (Level 0) to the incorporation of hypermedia as the application state engine (HATEOAS, Level 3).

In contrast to REST, other paradigms are also widely used. Remote Procedure Calls (RPC), for example, aim to allow the execution of functions on a remote server as if they were local calls (Birrel and Nelson, 1984). Although they simplify method invocation, RPC APIs tend to generate greater coupling between client and server, as communication is oriented towards specific actions, not resources. Another notable protocol is the Simple Object Access Protocol (SOAP), an XML-based standard that defines a structured format for messages and rigorous communication rules (W3C, 2007). SOAP is frequently employed in service-oriented architectures that demand formalization of contracts, high security, and reliability, but its complexity can be an obstacle in scenarios requiring greater agility. Finally, GraphQL, a query-oriented API specification, offers clients the flexibility to define exactly what data they wish to obtain, reducing the volume of data transferred and optimizing the efficiency of communication between frontend and backend, generally operating through a single HTTP endpoint (Porcello and Banks, 2018). The choice of API paradigm therefore depends on the specific project requirements, considering factors such as flexibility, coupling, performance, and ease of use.

The architectural perspective is also crucial in the classification and design of APIs, directly influencing the scalability, coupling, performance, and maintainability of applications. The monolithic architecture, as described by Newman (2020), consists of a single deployment unit where all functionalities are implemented and made available together. Although it may be simpler to develop and deploy initially, a single-process monolith, where all code runs as a single process, can face scalability and robustness challenges, even with multiple instances.

Source: Newman (2020)

Figure 1. Single process monolith: all code is executed in a single process

Figure 1 illustrates the basic structure of a single-process monolith, where the application and the database are tightly coupled. A variation, the modular monolith, organizes the system into logically distinct modules, which can be developed and maintained independently, but are still integrated and deployed as a single unit (Newman, 2020).

Source: Newman (2020)

Figure 2. Single process monolith: the code within the process is divided into modules

Figure 2 demonstrates this logical separation within a monolith, which can improve internal organization but does not completely resolve the deployment and scalability challenges inherent in a single unit. In contrast, the microservices architecture, as detailed by Newman (2021), consists of services that can be deployed independently, each structured around specific business domains and communicating via APIs. This approach avoids database sharing, with each service being responsible for its own data repository, promoting greater autonomy and resilience.

Source: Newman (2020)

Figure 3. Microservices: services are executed independently

Figure 3 represents the microservices architecture, highlighting the independence of services and their respective databases, which provides greater flexibility and scalability to the system. The adoption of microservices, although it brings additional complexity in management and orchestration, is often justified by the need for highly scalable, resilient systems with independent development cycles.

The characterization of the organization’s legacy cloud system architecture revealed a common scenario in equipment telemetry systems. Each piece of equipment manufactured by the company has an embedded module that acquires and transmits operational data, generating a significant volume of information. The existing backend, however, was structured as a monolith, where all functionalities were implemented and deployed as a single unit. This approach, although functional for an initial stage, presented significant limitations as the data volume and the demand for real-time interactivity grew. The exposure of functionalities to web and mobile frontends was carried out through a GraphQL-based API, which, despite offering flexibility in queries, concentrated business rules, data access, and service layers in a single process, impacting scalability and maintainability.

Source: Original research results

Figure 4. Main components of the current system

As illustrated in Figure 4, the legacy system presented a direct coupling between the service layer (Backend BFF / GraphQL) and the OLAP (Online Analytical Processing) database. This database, optimized to support large volumes of data and complex analytical queries, proved inefficient for scenarios requiring fast transactional responses and low latency. The use of an OLAP database to meet real-time demands resulted in slow information rendering on the user interface, compromising the overall experience. This limitation is a recurring problem in monolithic architectures that attempt to reconcile analytical and transactional workloads in the same data repository, highlighting the need for decoupling and optimization for different access profiles. The lack of clear separation between data ingestion, processing, and consumption responsibilities contributed to a less resilient system that was harder to scale horizontally, as any bottleneck in one part of the monolith affected the performance of the entire system.

The proposed new cloud architecture sought to resolve the limitations identified in the legacy system, adopting a hybrid approach that decouples analytical workloads from near real-time read demands. This restructuring was designed to ensure scalability, improve performance, and optimize data organization.

Source: Original research results

Figure 5. C4 diagram in container view

Figure 5, which presents the C4 diagram at the container level of the new architecture, details the separation of responsibilities. Field equipment continues to send telemetry data to a Data Ingestion Service via WebSocket, which persists it in the Analytical Database (OLAP). This step maintains compatibility with the legacy data collection system. The innovation lies in the introduction of a Data Consolidation Service, which processes and materializes the raw OLAP data, storing it in a Transactional Database (OLTP). This database is optimized for low-latency queries, meeting the needs of frontend applications. Users interact with the system through Web and Mobile Applications, which consume a REST API provided by the Backend for Frontend (BFF). This architecture promotes a fundamental decoupling between analytical processing and operational consumption, resulting in better performance for interactive use. The separation between OLAP and OLTP, with a data materialization process, is a practice aligned with the principles of modern data architectures that seek to optimize access and processing for different workloads, as discussed by Fowler (2002) in enterprise architecture patterns.

Source: Original research results

Figure 6. Main components of the proposed solution

Figure 6 complements the C4 diagram view, representing the main components of the proposed solution in three layers: presentation, services, and data. In the presentation layer, web and mobile clients consume data via API requests, displaying operational dashboards and reports. The services layer is composed of the Telemetry Ingestion Service (receiving data via WebSocket), the Materialization Service (consolidating OLAP data to OLTP), and the REST Backend/BFF API (abstracting data complexity and providing optimized responses). The data layer uses the OLAP database for raw telemetry data and the OLTP database for consolidated, low-latency data, essential for user management and authentication. This data flow, divided into write (collection, OLAP persistence, OLTP materialization) and read (frontend accessing API for consolidated OLTP data) processes, ensures greater efficiency and a better user experience. The Backend for Frontend (BFF) approach is particularly relevant here, as it allows the API to be adapted to the specific needs of each client type (web or mobile), reducing coupling and optimizing information consumption, a practice recommended by Newman (2020) for distributed architectures. Compatibility with the legacy system, maintaining the complete history of collected data, is an additional benefit that ensures operational integrity and continuity.

The development of the REST API was a central component of the research, focusing on the design and development of the service layer in the Backend for Frontend (BFF) pattern. This layer acts as a strategic intermediary between client applications and data repositories, allowing responses to be tailored to the specific needs of each type of frontend and its associated business rules. The adoption of the BFF pattern is a recognized practice for its ability to optimize the frontend developer experience by providing an API that is precisely shaped for the consumption of a specific application, rather than a generic API that attempts to serve multiple clients with different requirements. This minimizes data overhead and client-side complexity, resulting in more efficient and better-performing applications.

The structuring of the API endpoints followed a standardized route convention, composed of a technical prefix (`/api`), the identification of the consuming channel (`/web` or `/mobile`), an explicit versioning (`/v1`), and segmentation by functional domain (`/auth` and `/users`).

Source: Original research results

Figure 7. Endpoint decomposition

Figure 7 illustrates the endpoint decomposition, showing how each route segment contributes to the organization and clarity of the API. This design strategy is crucial for reducing coupling between clients and the API, as it allows different versions and consumption channels to coexist and evolve independently. Furthermore, it significantly improves the organization of API documentation, making it easier for developers to understand and use. The standardization of endpoints, as demonstrated in Table 1, which presents detailed examples of API endpoints by consumer channel, version, and functional domain, is a fundamental practice for API governance. Zimmermann et al. (2017) emphasize that API governance, including versioning and automated documentation (such as Swagger/OpenAPI), is essential for long-term sustainability and usability. The clarity and predictability of routes facilitate the integration of new services and the maintenance of existing ones, ensuring that the API is robust and adaptable to client needs and system evolution. Table 1, as presented in the Materials and Methods section, exemplifies this route convention, showing how different channels (web, mobile) and functional domains (authentication, users, equipment) are organized under explicit versioning, which is vital for managing API evolution without breaking existing integrations.

The unit tests for the authentication routes were crucial to validate the API’s security and functionality. Executing the test cases specified in Appendix A, using the `pytest` tool, allowed for a comprehensive analysis of functional and security scenarios.

Source: Original research results

Figure 8. Result of the automated authentication tests execution

Figure 8 presents the results of the authentication unit tests, showing that all 10 tests were Approved, with efficient execution times. These results demonstrate the API’s robustness in handling various authentication scenarios.

Firstly, the API correctly authenticates valid users, returning the expected data (CT01). This validates the basic login functionality, ensuring that users with correct credentials can access the system. The practical implication is the guarantee that the system’s main entry point is functional and reliable, allowing legitimate users to interact with the application without impediments. This finding is fundamental for the system’s usability and adoption, as a fluid authentication process is the basis for any secure interaction.

Secondly, the API properly rejects invalid or incomplete requests, with controlled error responses and no token issuance (CT02 and CT03). This behavior is vital for security, as it prevents unauthorized access attempts and provides clear feedback on authentication failures. The practice of returning standardized and informative error messages, without exposing internal system details, is a best practice for security that contributes to the API’s resilience against brute-force or social engineering attacks, as recommended by Madden (2020).

Third, the API correctly validates the mandatory nature and consistency of input data, treating incomplete or invalid requests with appropriate error responses (CT04, CT05, and CT06). This rigorous validation at the input layer is a primary defense against malicious data injection and ensures the integrity of processed information. Compliance with data types and mandatory fields is a pillar of robust API design, preventing processing errors and ensuring system stability.

Fourth, the API ensures adequate access control, preventing the authentication of inactive users (CT07). This is a critical security requirement, as it prevents deactivated or suspended accounts from being used to access the system. User state management, such as active/inactive, is an essential functionality for user governance and for maintaining system security over time, aligning with access control guidelines in distributed systems.

Fifth, the API presents compliance with the API contract, especially regarding the restriction of allowed HTTP methods (CT08). This means that the API responds with the HTTP status code 405 (Method Not Allowed) for unsupported methods on a given endpoint, ensuring that only expected operations are accepted. Adherence to HTTP methods (GET, POST, PUT, DELETE) and their semantic meanings is a fundamental principle of REST, as per Fielding (2000), which promotes interoperability and predictability of API behavior.

Sixth, the API maintains consistency in the response structure in success scenarios, meeting the defined requirements (CT09). The standardization of the response structure facilitates API consumption by clients, reducing integration complexity and development time. A consistent response structure is an indicator of a mature and well-documented API design, contributing to the developer experience.

Finally, the API meets the security criteria, not exposing sensitive information in the response “payload” (CT10). This is a crucial aspect of information security, preventing the accidental disclosure of confidential data that could be exploited by attackers. Filtering sensitive information in API responses is an essential security practice that protects user privacy and system integrity, according to API security best practices (Madden, 2020).

The unit tests related to the “token”-based authentication flow were equally successful, validating the mechanisms for generation, validation, renewal, and expiration of access tokens, as well as the handling of misuse.

Source: Original research results

Figure 9. Result of the execution of automated authentication tests

Figure 9 shows that all 15 token flow tests were passed, including a performance test, demonstrating the system’s robustness.

First, the system correctly generates access and renewal tokens for authenticated users (CT11 and CT18). This is fundamental for security and user experience, as tokens are the basis for accessing protected resources and maintaining an active session without the need for constant reauthentication. The correct generation of JSON Web Tokens (JWT) and refresh tokens, according to OAuth2 specifications, is a pillar of modern API security, ensuring that access credentials are ephemeral and manageable.

Secondly, the API allows access to protected routes only through the use of valid tokens (CT12). This token-based access control is essential to protect system resources against unauthorized access. The validation of each token on each request to a protected resource ensures that only authenticated and authorized users can interact with the sensitive functionalities of the application, reinforcing API security.

Third, the API properly rejects missing, invalid, malformed, or incorrectly used tokens (CT13, CT14, CT15, and CT21). This behavior is crucial for preventing token injection attacks or attempts to access with forged credentials. Robustness in token validation is a critical line of defense, ensuring that only legitimate and well-formed tokens are accepted, according to API security guidelines (Madden, 2020).

Fourth, the API ensures proper separation between *access token* and *refresh token*, preventing their misuse (CT16 and CT22). This separation is a recommended security practice, where the *access token* has a short lifespan and is used to access resources, while the *refresh token* has a longer lifespan and is used only to obtain new *access tokens*. This minimizes the risk of compromising long-lived credentials, as even if an *access token* is intercepted, its limited validity period reduces the attack window.

Fifth, the system correctly implements the token expiration mechanism, ensuring invalidation after the defined time (CT23 and CT24). Token expiration is an essential security component, as it limits the time a compromised token can be used. Validating token expiration, for both *access tokens* and *refresh tokens*, is fundamental for secure session management and for mitigating security risks.

Finally, the API presents adequate performance in authentication and token renewal operations (CT17). The efficiency in processing authentication and token renewal requests is vital for user experience and system scalability. Fast response times in these operations ensure that authentication does not become a performance bottleneck, even under high load, contributing to the sustainability of the architecture.

Idempotency unit tests for PUT and DELETE methods were performed to verify the consistency of resource states after multiple executions of the same operation, as well as the absence of unwanted side effects.

Source: Original research results

Figure 10. Result of the execution of automated idempotency tests

Figure 10 shows that all 6 idempotency tests were approved, with fast execution times.

First, the API maintains the consistency of the resource state after multiple executions of identical PUT requests, characterizing idempotent behavior (CT25). Idempotence is a fundamental principle of RESTful design, according to Richardson et al. (2007), which ensures that repeated execution of a PUT operation does not alter the resource state beyond the first execution. This is crucial for the reliability of distributed systems, where requests may be retried due to network or temporary failures, without causing data inconsistencies.

Secondly, the API does not generate data duplication when the same PUT operation is executed repeatedly (CT26). This finding reinforces the idempotence of the PUT method, ensuring that updating a resource does not result in the creation of duplicate records, which could lead to inconsistent data and database integrity issues. Duplication prevention is a direct benefit of the correct implementation of idempotence.

Third, the API ensures that successive DELETE requests keep the resource in an absent state, without reverting or altering the expected outcome (CT27). Similar to PUT, the DELETE method must be idempotent, meaning multiple requests to remove the same resource should result in the same final state (resource absent), without generating errors or side effects. This is essential for system robustness, allowing deletion operations to be safely retried.

Fourth, the API properly handles repeated DELETE calls, not causing internal server errors (CT28). The ability to handle repeated DELETE requests without internal failures demonstrates the API’s resilience. This is particularly important in distributed environments, where communication can be unstable and requests may be sent multiple times, and the API must be able to process them without compromising its stability.

Fifth, the API correctly uses the PUT method for resource updates, without undue side effects (CT29). The correct semantics of PUT, which is the complete replacement of a resource, are validated, ensuring that updates are predictable and do not introduce unintended effects into the system. This contributes to the clarity and maintainability of the API.

Finally, the API correctly applies the DELETE method for resource removal, ensuring predictable and consistent behavior (CT30). The DELETE validation confirms that resource removal occurs as expected, without leaving traces or inconsistent states. The predictability of HTTP method behavior is a pillar for building RESTful APIs that are easy to understand and integrate.

Unit tests for pagination were conducted to validate the device listing route’s pagination mechanism, covering functional scenarios, parameter validation, and API response consistency.

Source: Original research results

Figure 11. Result of the automated pagination tests execution

Figure 11 shows that all 15 pagination tests were approved, with consistent execution times.

First, the API correctly returns the first page of results, respecting the informed parameters (CT31). This validates the basic pagination functionality, ensuring that users can request and receive the first part of a dataset in a predictable manner. The correct implementation of pagination is essential for managing large data volumes, improving performance and user experience by avoiding the transfer of all data at once.

Secondly, the API allows navigation between distinct pages without undue repetition of records (CT32). The ability to navigate to subsequent pages without encountering duplicate records is crucial for the integrity of the presented data and for a fluid user experience. This demonstrates that the pagination mechanism is correctly managing data offsets and limits between requests.

Third, the API respects the item limit defined by the `page_size` parameter (CT33). Enforcing `page_size` ensures that the amount of data returned in each request is controlled, optimizing bandwidth usage and client processing time. This flexibility allows clients to adjust the pagination granularity according to their needs.

Fourth, the API correctly applies default pagination when parameters are not informed (CT34). Defining a default behavior for pagination, when the `page` and `page_size` parameters are not provided, is a good API design practice that improves usability and robustness, ensuring that the API always returns a paginated dataset, even in simplified requests.

Fifth, the API properly handles requests for pages beyond the total available, returning a controlled response (CT35). Instead of generating a server error, the API should return a response indicating that the requested page is empty or does not exist, which is an expected and robust behavior. This avoids unexpected failures and provides clear feedback to the client.

Sixth, the API rejects invalid values for the `page` parameter, such as zero or negative numbers (CT36 and CT37). Rigorous validation of input parameters is fundamental for API security and stability, preventing malicious or incorrect values from causing unexpected behaviors or internal errors.

Seventh, the API rejects invalid values for the `page_size` parameter, such as zero or negative values (CT38 and CT39). Similarly to the `page` parameter, the validation of `page_size` ensures that only positive and reasonable values are accepted, avoiding requests that could overload the server or return unwanted results.

Eighth, the API correctly limits the maximum value of `page_size` or handles excessive values in a controlled manner (CT40). Imposing a maximum limit for `page_size` is a security and performance measure, preventing a client from requesting an excessively large number of items in a single request, which could lead to performance bottlenecks or denial-of-service attacks.

No, the API validates the type of pagination parameters, rejecting non-numeric values (CT41 and CT42). Data type validation is an essential security practice, ensuring that only numeric inputs are accepted for the `page` and `page_size` parameters, protecting the API against code injection or other attacks based on incorrect data types.

Tenth, the API maintains the consistency of the paginated response structure, as per the API contract (CT43). The standardization of the response structure, including metadata such as `count`, `next`, and `results`, facilitates API consumption by clients and ensures a consistent integration experience.

Eleventh, the API ensures the absence of undue record overlap between consecutive pages (CT44). The absence of overlap is crucial for data integrity and to ensure that each record is presented only once during paginated navigation.

Finally, the API correctly applies pagination in conjunction with filters, maintaining the consistency of the returned results (CT45). The ability to combine pagination with filters is an advanced functionality that allows users to refine their searches in large datasets efficiently, demonstrating the API’s flexibility and robustness.

In summary, the diagnosis of the legacy architecture revealed significant limitations in the exclusive use of OLAP for real-time service, resulting in high latency and coupling with the frontend. The adoption of a hybrid architecture, with the separation between OLAP and OLTP and the implementation of a data materialization process, proved to be an effective solution. This approach brought substantial performance and organizational gains, enabling faster and more consistent queries, which aligns with best practices in distributed systems design (Fowler, 2002). The implementation of an API following the Backend for Frontend (BFF) pattern, along with the definition of business rules and a rigorous battery of validation tests, increased the reliability and suitability of customer responses. The results of the unit tests for authentication, token flow, idempotency, and pagination confirmed the API’s compliance with functional and security requirements, as well as its adherence to good RESTful design practices, according to Richardson et al. (2007) and Madden (2020).

The practical implications of these results are vast. Reducing query latency directly improves the end-user experience, making applications more responsive and efficient. Decoupling analytical and operational workloads increases system scalability, allowing it to support a growing volume of data and users without compromising performance. The standardization of data access via REST API and the robustness of authentication and validation mechanisms contribute to the long-term security and maintainability of the system. The ability to filter and structure data more efficiently optimizes the utilization of computational resources and provides a solid foundation for strategic decision-making.

As future improvements, the evolution towards near real-time data materialization, the use of cache to optimize read performance, the implementation of greater observability (monitoring and logs), and the continuous maturation of engineering practices are crucial aspects to ensure the continuous scalability and robustness of the architecture. Additionally, it becomes essential to expand security testing, including authorization validations, protection against known vulnerabilities (OWASP Top 10), and load testing focused on critical scenarios. These additional measures will ensure the integrity, confidentiality, and availability of the system, consolidating the proposed architecture as an advanced and sustainable technological solution.