Author
Abstract
Most of the financial platforms increasingly adopt event driven and cloud native microservices, managing Quality of Service (QoS) across different client traffic has become critical. Traditional RESTful APIs treat all traffic equally, but in the financial services where traffic can be huge, where transactions range from real-time institutional trades to batch processing for retail clients, a one-size-fits-all approach to API performance is inadequate. With this research, I present a novel architectural framework for Priority-Aware Reactive APIs using Spring WebFlux, enabling differentiated request handling based on SLA tiers such as Gold, Silver, and Bronze. My strategy incorporates reactive programming principles, backpressure-aware load management, and custom schedulers to dynamically prioritize traffic at runtime. By using SLA logic at the WebFlux filter and controller layers, the system shapes incoming traffic using token-bucket-style schedulers, assigns compute resources based on traffic importance, and enforces response-time guarantees for high-value clients even during load spikes. The architecture leverages Reactor’s Scheduler abstraction, bounded elastic pools, and rate-limit-aware filter chains to support real-time priority demarcation with minimal overhead. In order to validate this model, methodology involved developing reactive microservices, and simulating concurrent API traffic mimicking diverse financial operations, order placement, fund transfer, balance inquiries across SLA tiers using Prometheus and Grafana for observability. I benchmark system performance under synthetic load conditions and failure scenarios, revealing that SLA-aware routing achieves up to 60% lower latency for Gold-tier operations during resource contention, while maintaining service for lower tiers without system-wide degradation. With this study fills a gap in current reactive architecture literature by introducing SLA-aware traffic shaping in reactive streams a key consideration for systems governed by regulatory and customer experience obligations. My results demonstrate how financial platforms can enhance system fairness, customer trust, and operational resilience using Spring WebFlux without sacrificing throughput. This architecture can be extended to other SLA-sensitive sectors like Telecom, healthcare and real-time logistics, offering a practical, scalable approach to SLA isolation in reactive microservice systems.
Suggested Citation
Kishore Subramanya Hebbar, 2025.
"Priority-Aware Reactive APIs: Leveraging Spring WebFlux for SLA-Tiered Traffic in Financial Services,"
European Journal of Electrical Engineering and Computer Science, European Open Science, vol. 9(5), pages 31-40, September.
Handle:
RePEc:epw:ejece0:v:9:y:2025:i:5:id:19743
DOI: 10.24018/ejece.2025.9.5.743
Download full text from publisher
Corrections
All material on this site has been provided by the respective publishers and authors. You can help correct errors and omissions. When requesting a correction, please mention this item's handle: RePEc:epw:ejece0:v:9:y:2025:i:5:id:19743. See general information about how to correct material in RePEc.
If you have authored this item and are not yet registered with RePEc, we encourage you to do it here. This allows to link your profile to this item. It also allows you to accept potential citations to this item that we are uncertain about.
We have no bibliographic references for this item. You can help adding them by using this form .
If you know of missing items citing this one, you can help us creating those links by adding the relevant references in the same way as above, for each refering item. If you are a registered author of this item, you may also want to check the "citations" tab in your RePEc Author Service profile, as there may be some citations waiting for confirmation.
For technical questions regarding this item, or to correct its authors, title, abstract, bibliographic or download information, contact: support (email available below). General contact details of provider: https://eu-opensci.org/index.php/ejece .
Please note that corrections may take a couple of weeks to filter through
the various RePEc services.