Pith. sign in

REVIEW 4 major objections 5 minor 77 references

A microservice ticketing design reports 31 ms average query response, 817 requests/second throughput, and zero oversold tickets, using an atomic Redis token container for inventory.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

A railway ticketing system built from standard Spring Cloud components is reported to reach 817 req/s on a train-query interface, but only under a 100-thread local VM test with inconsistent purchase-interface data.

T0 review reviewed 2026-08-03 challenge →

load-bearing objection A competent engineering write-up of a standard microservices ticketing stack, but the performance evidence is self-contradictory and there is no research contribution. the 4 major comments →

arxiv 2512.24941 v2 pith:MATPWJW2 submitted 2025-12-31 cs.SE

Securing High-Concurrency Ticket Sales: A Framework Based on Microservice

Zhiyong Zhang , Xiaoyan Zhang , Xiaoqi Li This is my paper
classification cs.SE
keywords microservicesrailway ticketinghigh concurrencyRedis cacheinventory tokencache consistencyBloom Filterperformance testing
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper tries to establish that a railway ticketing system built as five independent Spring Cloud microservices, protected by a stack of caching, traffic-control, and data-consistency measures, can stay stable and consistent under heavy concurrent ticket buying. The core performance claim is concrete: the train-query interface averaged 31 milliseconds and 817 requests per second with no errors, while the purchase interface averaged 65 milliseconds with zero oversold tickets. The authors argue that the key to preventing overselling is an atomic Redis token container that deducts inventory per route-and-seat-type, backed by binlog-driven asynchronous cache updates. A sympathetic reader would care because the design turns known middleware components into a repeatable template for high-contention reservation systems.

Core claim

The paper claims that a railway ticketing system built from five Spring Cloud microservices, with a Redis cache layer, Canal-driven binlog synchronization, a Bloom Filter guard, and an atomic Redis token container that deducts inventory with INCRBY, remains stable and consistent under high concurrency: the train-query interface averaged 31 ms response time and 817 requests/second with 0% anomalies, and the ticket-purchase interface averaged 65 ms and 265 requests/second with zero oversold tickets.

What carries the argument

The central mechanism is the Redis-based inventory token container: a Redis Hash whose fields are route-and-seat-type keys and whose values are remaining ticket counts. Deducting a ticket is a single atomic INCRBY call on the hash field, so Redis's single-threaded execution serializes concurrent deductions and rejects requests when the count would go negative. The paper couples this with Canal reading MySQL binlog to asynchronously refresh the cache, and a Bloom Filter ahead of the cache to stop requests for nonexistent data from reaching the database.

Load-bearing premise

The load-bearing premise is that a 100-thread staged load test on a local virtual machine, with hand-tuned JVM and Tomcat limits, is a faithful stand-in for the hundreds of millions of concurrent accesses the introduction cites—if that scale mismatch is real, the stability and no-oversell conclusions are unsupported.

What would settle it

Run the same system with, say, 10,000 concurrent threads spread across multiple application instances behind a load balancer (or a realistic flash-crowd pattern), and check whether the Redis token container still yields zero oversold tickets and whether response-time percentiles stay within the reported range; alternatively, verify that the token container lives on a single Redis node, since INCRBY atomicity does not survive sharding.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

If this is right

  • If the design holds, high-contention inventory systems can prevent overselling with a single atomic counter rather than distributed locks.
  • The measured 31 ms query average suggests the layered cache plus Bloom Filter combination can cut core-interface latency by roughly 6x versus the 200 ms baseline.
  • The architecture provides a repeatable template: microservice decomposition plus traffic control plus binlog-driven cache sync can be assembled from existing middleware components.
  • Because the test ran on one VM, real deployments would need multi-instance horizontal scaling, and the paper's own 2.01% error rate on the purchase interface points to where headroom must be added.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The performance claims rest on a 100-thread local VM test; treating that as evidence for 'hundreds of millions' of concurrent accesses is a stretch, and real validation would need cluster-scale load tests.
  • Redis INCRBY is atomic only within one Redis instance; if the token container is sharded across Redis nodes, the no-oversell guarantee requires additional coordination, so the claim as stated may not carry over to a sharded deployment.
  • The Bloom Filter's 99% interception claim is plausible for random keys but depends on filter sizing and hash functions; an adversarial key distribution would probe whether the cache-penetration protection holds.
  • The binlog-driven cache sync is asynchronous, so a window exists where cache and database disagree; the token container masks this for inventory, but other cached data may serve stale values.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper describes a railway ticketing system built on a microservice architecture (Spring Cloud Alibaba), with membership, ticketing, order, payment, and gateway modules. It claims several security mechanisms: Sentinel rate limiting, Bloom Filter plus Redis for cache-penetration protection, Canal-based binlog monitoring with RocketMQ for cache consistency, and a Redis token container for atomic inventory deduction. The empirical evaluation in Section 4.3 uses JMeter on a local virtual machine with at most 100 threads and reports throughput and latency for the train query and ticket purchase interfaces. The paper concludes that the system is stable and reliable under high concurrency and that no overselling occurs.

Significance. If the empirical claims were supported, the paper would provide a useful reference architecture for a high-concurrency ticketing system. The choice of middleware is standard and the token-container idea using Redis INCRBY is a reasonable pattern for serializing inventory decrements. However, the paper provides no reproducible artifacts (code, test scripts, or raw data), and the only displayed performance table for the ticket purchase flow contradicts the textual summary. The central claims about high-concurrency stability, Bloom-filter interception, and zero overselling are not backed by consistent, testable evidence.

major comments (4)
  1. [§4.3, Tables 4.1 and 4.2] Table 4.2, labeled "Performance Test Data of Ticket Purchase Interface," is numerically identical to Table 4.1 (Sample=5729, Average=31, Median=37, 90th=39, 99th=50, Min=13, Max=122, Anomaly Rate=0.00%, Throughput=817/sec, Receive=2581.06 KB/s, Send=211.24 KB/s). The paragraph directly below states that the ticket purchase interface had an average response time of 65 ms, throughput of 265 requests/s, and an anomaly rate of 2.01% due to thread-pool exhaustion. Those figures are absent from Table 4.2. This is a load-bearing inconsistency: the table is the only displayed evidence for the purchase workflow, which is exactly the workflow behind the stability and zero-overselling conclusions. A copy-paste error would still leave the paper without supporting data; if the table is accurate, the prose is unsupported.
  2. [§4.3 and §5] The test setup is a local virtual machine with a staged ramp-up to 100 threads (Section 4.3). The Introduction frames the problem with "hundreds of millions" of concurrent accesses and "billions of ticket requests daily," and the Conclusion generalizes the 100-thread result to a claim of reliability and stability under high concurrency. No evidence is provided that 100 threads on a single local VM is representative of the claimed workload. The authors themselves report thread-pool exhaustion and a 2.01% anomaly rate for the purchase interface under this small load. The paper must state a workload model and justify the extrapolation; as written, the inference is a significant external-validity gap.
  3. [§5 (zero overselling) and §4.1.4] The Conclusion asserts "zero overselling of tickets," but Section 4.3 contains no test that measures overselling, no concurrency assertion, and no audit of final inventory versus order states. The token-container mechanism in §4.1.4 is described as preventing overselling through Redis INCRBY atomicity, but no multi-instance or high-contention experiment is presented. The paper also does not discuss behavior if the Redis container is partitioned, replicated with asynchronous failover, or bypassed by a retry path. The zero-overselling claim is therefore unsubstantiated by the reported evaluation.
  4. [§1 and §5 (Bloom Filter / response-time claims)] The innovation list in the Introduction claims the Bloom Filter "intercept[s] 99% of invalid requests" and reduces "core interface response time from 200ms to 30ms." No experiment in Section 4.3 measures interception rate or provides a baseline without the Bloom Filter. The Conclusion changes the response-time claim to "less than 40 milliseconds," which is inconsistent with the 30 ms figure. These quantitative claims are load-bearing for the paper's stated novelty and need direct measurements or removal.
minor comments (5)
  1. [Eq. (2-8)] The Bloom-filter false-positive formula appears to be mistyped: the standard form is approximately (1 - e^{-kn/m})^k, but the equation as printed omits the negative exponent and uses a symbol resembling kappa.
  2. [Various] There are typos: Section 5 heading "CONCILUSION" should be "CONCLUSION", and Figure 2.10 caption "Schematic Ciagram" should be "Schematic Diagram".
  3. [Introduction and Conclusion] The claimed response-time improvement appears as "200ms to 30ms" in Section 1 and as "less than 40 milliseconds" in Section 5. Align the numbers and provide the baseline measurement that supports either figure.
  4. [References] The reference list contains numerous arXiv preprints on blockchain and smart-contract security (e.g., [36]–[39], [42], [49], [52], [54], [56], [58], [60], [62], [66], [73]) that are not cited in support of any ticketing-system claim. Several are self-citations. These should be pruned or explicitly justified.
  5. [Reproducibility] No source code, test scripts, configuration files, or JMeter result files are provided. The described system cannot be independently reproduced or re-benchmarked from the manuscript.

Circularity Check

0 steps flagged

No circular derivation: the paper's performance claims are reported measurements and standard engineering descriptions, not fitted inputs or self-referential results.

full rationale

The paper does not contain a derivation chain in which an output is defined in terms of an input or in which a fitted parameter is relabeled as a prediction. The central performance claims (Section 4.3 and Section 5) are presented as JMeter measurements: 31 ms / 817 req/s for the train-query interface and 65 ms / 265 req/s for the ticket-purchase interface, with no model fitted to those numbers and no prediction generated from them. The Redis INCRBY token-container argument (Section 4.1.4) is an assertion of atomicity for a standard single-threaded primitive, not an equation derived from the conclusion. The self-citations by author Xiaoqi Li (e.g., references [37] and [39], cited for the Snowflake algorithm) are irrelevant to the ticketing system and non-load-bearing; no uniqueness theorem or ansatz is imported from prior work. The serious internal problem is data integrity, not circularity: Table 4.2 is byte-for-byte identical to Table 4.1, while the text below it reports different metrics (65 ms, 265 req/s, 2.01% anomaly rate) that do not appear in the table, and Section 5's 'zero overselling' claim has no audit trail. Section 4.3 also states that the test was run on a local virtual machine with at most 100 threads, an explicitly acknowledged limitation that affects external validity but not circularity. Because no claim reduces by construction to its own inputs, the circularity score is 0.

Axiom & Free-Parameter Ledger

2 free parameters · 5 axioms · 0 invented entities

The central performance/stability claim depends on standard domain assumptions about middleware behavior and on hand-chosen test settings; no new scientific entities are introduced.

free parameters (2)
  • JMeter maximum thread count = 100
    Section 4.3: the load test ramps to 100 threads; this user scale is chosen by the authors and defines the 'high concurrency' being tested, while the introduction claims hundreds of millions of concurrent accesses.
  • Tomcat and JVM tuning parameters = JVM max/min heap 4000 MB; Tomcat max/min threads 300/300; max connections 100,000; max request throughput 1000; max queu
    Section 4.3: these values are hand-set before the test and directly affect throughput, response time, and error rate; the ticket-purchase thread-pool exhaustion is attributed to local resource limits.
axioms (5)
  • domain assumption Microservice decomposition yields better availability and scalability than a monolithic deployment.
    Section 1 and Section 2.1 assert this; no quantitative evidence is provided in the paper.
  • domain assumption Redis single-threaded INCRBY is atomic and therefore prevents overselling.
    Section 4.1.4 bases the anti-overselling mechanism on Redis atomicity; this holds for a single Redis instance but the paper does not analyze multi-instance or sharded deployment.
  • domain assumption Canal parsing of MySQL binlog plus RocketMQ asynchronous delivery keeps cache and database consistent.
    Section 4.1.3 relies on this pipeline; the paper does not demonstrate ordering, at-least-once, or failure-handling properties.
  • standard math Standard Bloom Filter false-positive rate formula p≈(1−e^{−kn/m})^k.
    Section 2.4(3) uses this textbook formula; no issue.
  • standard math AES round transformations (SubBytes, ShiftRows, MixColumns, AddRoundKey) are as specified by the standard.
    Section 2.4(1) restates the AES description; acceptable as standard background.

reviewed 2026-08-03 · how reviews work

0 comments
Cite this review

Pith. "Pith review of Securing High-Concurrency Ticket Sales: A Framework Based on Microservice." pith.science (2026). https://pith.science/paper/MATPWJW2

@misc{pith2026251224941,
  author       = {Pith},
  title        = {Pith review of: Securing High-Concurrency Ticket Sales: A Framework Based on Microservice},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/MATPWJW2}},
  note         = {Machine review of arXiv:2512.24941}
}
Share X Bluesky LinkedIn Reddit HN
read the original abstract

The railway ticketing system is one of the most important public service infrastructure. In peak periods such as holidays, it is often faced with the challenge of high concurrency scenarios because of a large number of users accessing at the same time. The traditional aggregation architecture can not meet the peak user requirements because of its insufficient fault tolerance and low ability. Therefore, the system needs to use microservice architecture for development, and add multiple security methods to ensure that the system can have good stability and data consistency under high concurrency scenarios, and can respond quickly to user requests. This paper introduces the use of B/S architecture and Spring Cloud to design and develop a railway ticket purchase system that can maintain stability and reliability under high concurrency scenarios, and formulate multiple security design methods for the system. This system integrates a range of functions, such as real-time train inquiries, dynamic seat updates, online seat selection, and ticket purchasing, effectively addressing common problems associated with offline ticket purchasing, such as long queues and delayed information. It enables a complete online process from inquiry and booking to payment and refunds. Furthermore, the "add passenger" function allows users to purchase tickets for others, extending the convenience of online ticketing to people with limited internet access. The system design prioritizes security and stability, while also focusing on high performance, and achieves these goals through a carefully designed architecture and the integration of multiple middleware components. After the completion of the system development, the core interface of the system is tested, and then the results are analyzed. The test data proves that the system has good ability and stability under high concurrency.

Figures

Figures reproduced from arXiv: 2512.24941 by Xiaoqi Li, Xiaoyan Zhang, Zhiyong Zhang.

Figure 2.1
Figure 2.1. Figure 2.1: Spring Framework Architecture Diagram (2)Spring Boot The Spring framework[15] requires a lot of configuration, which can easily lead to various exceptions and low development efficiency. Spring Boot adopts the concept of ”convention over configuration” and optimizes the conventional development model. Its core technologies include an auto-wiring mechanism based on conditional configuration, starter depen… view at source ↗
Figure 2.2
Figure 2.2. Figure 2.2: Spring Application Execution Flowchart This framework significantly lowers the barrier to entry for Spring applications by sim￾plifying environment configuration and reducing boilerplate code. It also adapts to the microservice architecture requirements of the cloud-native era, becoming the mainstream industry standard for rapidly building production-grade applications and demonstrating sig￾nificant engi… view at source ↗
Figure 2.3
Figure 2.3. Figure 2.3: Schematic Diagram of Monolithic Architecture [PITH_FULL_IMAGE:figures/full_fig_p006_2_3.png] view at source ↗
Figure 2
Figure 2. Figure 2: is a schematic diagram of microservice architecture. [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 2.4
Figure 2.4. Figure 2.4: Schematic Diagram of Microservice Architecture [PITH_FULL_IMAGE:figures/full_fig_p006_2_4.png] view at source ↗
Figure 2.5
Figure 2.5. Figure 2.5: Schematic diagram of Spring Cloud Microservice Functional Components [PITH_FULL_IMAGE:figures/full_fig_p007_2_5.png] view at source ↗
Figure 2.6
Figure 2.6. Figure 2.6: Redis Data Types Redis is used as a caching layer to intercept high-frequency requests and reduce the load on the MySQL database. The MySQL database serves as the persistent layer for core data storage (as shown in [PITH_FULL_IMAGE:figures/full_fig_p008_2_6.png] view at source ↗
Figure 2.8
Figure 2.8. Figure 2.8: Schematic Diagram of Canal Working Principle [PITH_FULL_IMAGE:figures/full_fig_p009_2_8.png] view at source ↗
Figure 2.9
Figure 2.9. Figure 2.9: Snowflake Algorithm Structure Diagram The Snowflake algorithm is composed of four parts. The first part is the sign bit, occupying 1 bit. The second part is the timestamp, which uses 41 bits. The third part is the identifier bit, comprising 10 bits in total, with 5 bits allocated to the datacenterId and the other 5 bits to the workerId. These two identifiers are usually combined to represent different de… view at source ↗
Figure 2.10
Figure 2.10. Figure 2.10: Schematic Ciagram of a Bloom Filter The formula for calculating the false positive rate of a Bloom Filter is shown in Formula 2-8. p ≈  1 − e kn m κ (2-8) The core parameters are the number of elements n, the size of the binary array m, and the number of hash functions k. Therefore, the required binary array size m for calculating the false positive rate can be derived as shown in Formula 2-9. Zhiyong… view at source ↗
Figure 3.1
Figure 3.1. Figure 3.1: Functional Requirements Structure Diagram of Railway Ticketing System [PITH_FULL_IMAGE:figures/full_fig_p013_3_1.png] view at source ↗
Figure 3.2
Figure 3.2. Figure 3.2: Overall Architecture Diagram of Railway Ticketing System [PITH_FULL_IMAGE:figures/full_fig_p016_3_2.png] view at source ↗
Figure 3.3
Figure 3.3. Figure 3.3: E-R Diagram of Railway tTicketing System Database [PITH_FULL_IMAGE:figures/full_fig_p017_3_3.png] view at source ↗
Figure 3.4
Figure 3.4. Figure 3.4: E-R Diagram of Railway Ticketing System Database [PITH_FULL_IMAGE:figures/full_fig_p018_3_4.png] view at source ↗
Figure 3.5
Figure 3.5. Figure 3.5: E-R Diagram of Railway Ticketing System Database [PITH_FULL_IMAGE:figures/full_fig_p018_3_5.png] view at source ↗
Figure 3.6
Figure 3.6. Figure 3.6: E-R Diagram of Railway Ticketing System Database [PITH_FULL_IMAGE:figures/full_fig_p019_3_6.png] view at source ↗
Figure 3.7
Figure 3.7. Figure 3.7: E-R Diagram of Railway Ticketing System Database [PITH_FULL_IMAGE:figures/full_fig_p019_3_7.png] view at source ↗
Figure 3.8
Figure 3.8. Figure 3.8: E-R Diagram of Railway Ticketing System Database [PITH_FULL_IMAGE:figures/full_fig_p020_3_8.png] view at source ↗
Figure 4.1
Figure 4.1. Figure 4.1: Sentinel Rate Limiting Scheme 4.1.2 Database Stability and High Performance When using ShardingSphere for database sharding, choosing the appropriate sharding key is crucial. The system needs to consider several factors when selecting a sharding key, using a user ID can centralize user-related data, but frequent access by multiple users might lead to hotspot issues. On the other hand, using continuously … view at source ↗
Figure 4.2
Figure 4.2. Figure 4.2: Cache Penetration Solution The final solution chosen for this system combines Bloom Filter with caching, which avoids frequent database penetration queries and essentially solves the cache penetration problem. Zhiyong Zhang et al.: Preprint Submitted to Arxiv. 22 [PITH_FULL_IMAGE:figures/full_fig_p022_4_2.png] view at source ↗
Figure 4.3
Figure 4.3. Figure 4.3: Sequence Diagram of Database And Cache Consistency Solution [PITH_FULL_IMAGE:figures/full_fig_p023_4_3.png] view at source ↗
Figure 4.4
Figure 4.4. Figure 4.4: Token Container Diagram If a user wants to buy a ticket, the token container needs to be deducted first. Successful deduction means there are enough tickets left. Failure to deduct results in the request being rejected. This allows only those with the required number of tickets to receive tokens and enter the system, achieving rate limiting. Furthermore, because Redis uses a single-threaded model, the to… view at source ↗
Figure 4.5
Figure 4.5. Figure 4.5: Principle of Token-Based Rate Limiting 4.2 Function Implementation (1) Membership Services The user registration interface adopts a responsive form layout, including required fields such as username, password, ID card number, and mobile phone number. The front-end ver￾ifies the compliance of the 18-digit ID card format through a real-time validation mechanism and performs 11-digit numeric regular express… view at source ↗
Figure 4.6
Figure 4.6. Figure 4.6: Implementation Schematic 4.3 Testing and Evaluation After the system’s functionality and security design are implemented, it’s necessary to scientifically test the performance metrics of the core functional interfaces frequently ac￾cessed by users, and then evaluate and analyze the generated test reports. The purpose of performance testing is to obtain the system’s performance metrics to see if it meets … view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

77 extracted references · 7 linked inside Pith

  1. [1]

    Simu- lation study of pedestrian flow in a station hall during the Spring Festival travel rush

    Wang, Lei and Zhang, Qian and Cai, Yun and Zhang, Jianlin and Ma, Qingguo. “Simu- lation study of pedestrian flow in a station hall during the Spring Festival travel rush.” Physica A: Statistical Mechanics and its Applications392, no. 10 (2013): 2470-2478

    2013

  2. [2]

    AirTech Odyssey: A Web Application for Air Travel Reservations

    Joshi, Poorvi K and Bubana, Bhaven and Gillarkar, Tanvi and Warade, Pratham and Chetalangia, Yash and Qureshi, Sameed. “AirTech Odyssey: A Web Application for Air Travel Reservations.” In2024 3rd International Conference on Automation, Computing and Renewable Systems (ICACRS), pp. 225-230. IEEE, 2024

    2024

  3. [3]

    Built on SpringBoot’s travel platform

    Deng, Fei. “Built on SpringBoot’s travel platform.” In5th International Conference on Computer Information Science and Application Technology (CISAT 2022), vol. 12451, pp. 715-718. SPIE, 2022

    2022

  4. [4]

    The Research and Implementation of Intercity Railway Ticketing System

    Li, Feng and Wu, Gang and Zhang, Liming and Chen, Jing and Liu, Wenge. “The Research and Implementation of Intercity Railway Ticketing System.” InProceedings of the 1st International Workshop on High-Speed and Intercity Railways: Volume 1, pp. 57-67. Berlin, Heidelberg: Springer Berlin Heidelberg, 2012

    2012

  5. [5]

    Research on risk assessment tech- nology of China’s railway ticket selling and reservation system

    Zhao, Yingming and Zhang, Dedong and Li, Jubao. “Research on risk assessment tech- nology of China’s railway ticket selling and reservation system.” InJournal of Physics: Conference Series, vol. 1325, no. 1, p. 012006. IOP Publishing, 2019

    2019

  6. [6]

    The Passenger Preferences for Flexible Tickets and Key Attributes for Ticket Design of High-speed Railway: A Case Study from China

    Bai, Jian and Peng, Junchao and Wei, Yingfeng and Xu, Shuo and Yan, Zhenying and Lu, Jiaqing. “The Passenger Preferences for Flexible Tickets and Key Attributes for Ticket Design of High-speed Railway: A Case Study from China.”Urban Rail Tran- sit(2025): 1-14

    2025

  7. [7]

    Rail systems viewed from a system of systems perspective

    Hoehne, Oliver. “Rail systems viewed from a system of systems perspective.”Insight 19, no. 3 (2016): 36-38

    2016

  8. [8]

    Performance and Availability Analysis of API Design Techniques for API Gateways

    Aydemir, Fikri, and Fatih Ba¸ s¸ cift¸ ci. “Performance and Availability Analysis of API Design Techniques for API Gateways.”Arabian Journal for Science and Engineering 50, no. 15 (2025): 11485-11498

    2025

  9. [9]

    Design and Implementation of Online Food Ordering System Based on Springcloud

    Yang, Yu. “Design and Implementation of Online Food Ordering System Based on Springcloud.”Information Systems and Economics (2022) Clausius Scientif ic Press, Canada. DOI10 (2022)

    2022

  10. [10]

    Are railways really that Zhiyong Zhang et al.: Preprint Submitted to Arxiv.29 bad? An evaluation of rail systems performance in Europe with a focus on passenger rail

    Fraszczyk, Anna and Lamb, Thomas and Marinov, Marin. “Are railways really that Zhiyong Zhang et al.: Preprint Submitted to Arxiv.29 bad? An evaluation of rail systems performance in Europe with a focus on passenger rail.”Transportation Research Part A: Policy and Practice94 (2016): 573-591

    2016

  11. [11]

    Dynamic Scaling and Performance Optimization for Mi- croservices using Kubernetes

    Vishnivetskii, Konstantin. “Dynamic Scaling and Performance Optimization for Mi- croservices using Kubernetes.”Asian Journal of Research in Computer Science18, no. 3 (2025): 213-220

    2025

  12. [12]

    Spring framework for rapid open source J2EE Web application development: a case study

    Arthur, John and Azadegan, Shiva. “Spring framework for rapid open source J2EE Web application development: a case study.” InSixth International Conference on Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing and First ACIS International Workshop on Self-Assembling Wireless Network, pp. 90-95. IEEE, 2005

    2005

  13. [13]

    Spring framework reliability investigation against database bridging layer using Java platform

    Ginanjar, Arief and Hendayun, Mokhamad. “Spring framework reliability investigation against database bridging layer using Java platform.”Procedia Computer Science161, pp.1036-1045

  14. [14]

    Ganeshan, Amuthan.Spring MVC: Beginner’s Guide.Packt Publishing Ltd, 2016

    2016

  15. [15]

    Analysis and Research on Application Development Technology Based on SpringBoot Framework

    Yongping, Xiong. “Analysis and Research on Application Development Technology Based on SpringBoot Framework.”Computer Knowledge and Technology: Academic Edition 15.12 X2 (2019)

    2019

  16. [16]

    Software build automation tools a comparative study between maven, gradle, bazel and ant

    Prakash, Mridula. “Software build automation tools a comparative study between maven, gradle, bazel and ant.”Int J Softw Eng Appl13 (2022): 1-20

    2022

  17. [17]

    Performance analysis of microservice design patterns

    Akbulut, Akhan and Perros, Harry G. “Performance analysis of microservice design patterns.”IEEE Internet Computing23, no. 6 (2019): 19-27

    2019

  18. [18]

    Design and Implementation of a High Concurrency Online Payment Platform Based on Distributed Microservice Architecture

    Huang, Tianyou. “Design and Implementation of a High Concurrency Online Payment Platform Based on Distributed Microservice Architecture.”The International Confer- ence on Cyber Security Intelligence and Analytics, pp. 551-560. Cham: Springer Nature Switzerland, 2024

    2024

  19. [19]

    Practice of Alibaba cloud on elastic resource provisioning for large-scale microservices cluster

    Xu, Minxian and Yang, Lei and Wang, Yang and Gao, Chengxi and Wen, Linfeng and Xu, Guoyao and Zhang, Liping and Ye, Kejiang and Xu, Chengzhong. “Practice of Alibaba cloud on elastic resource provisioning for large-scale microservices cluster.” Software: Practice and Experience.54, no. 1 (2024): 39-57

    2024

  20. [20]

    Spring microservices in action

    Carnell, John, and Illary Huaylupo S´ anchez. “Spring microservices in action.”Simon and Schuster, 2021

    2021

  21. [21]

    Christudas, Binildas.Practical microservices architectural patterns: event-based java microservices with spring boot and spring cloud.Apress, 2019

    2019

  22. [22]

    Design methods for the new database era: a systematic literature review

    Roy-Hubara, Noa and Sturm, Arnon. “Design methods for the new database era: a systematic literature review.”Software and Systems Modeling19, no. 2 (2020): 297- Zhiyong Zhang et al.: Preprint Submitted to Arxiv.30 312

    2020

  23. [23]

    A performance benchmark for the post- gresql and mysql databases

    Salunke, Sanket Vilas, and Abdelkader Ouda. “A performance benchmark for the post- gresql and mysql databases.”Future Internet16, no. 10 (2024): 382

    2024

  24. [24]

    Redis-based messaging queue and cache-enabled parallel processing social media analytics framework

    Singh, Ravindra Kumar and Verma, Harsh Kumar. “Redis-based messaging queue and cache-enabled parallel processing social media analytics framework.”The computer jour- nal65, no. 4 (2022): 843-857

    2022

  25. [25]

    Research and application of distributed cache based on Redis

    Shi, L., H. Qiao, C. Yang, Y. Jiang, K. Yu, and C. Chen. “Research and application of distributed cache based on Redis.”Journal of Software19, no. 1 (2024): 1-8

    2024

  26. [26]

    Xuemei, and M

    Fangmei, N., H. Xuemei, and M. Jinjuan. ”Application of spring boot integrated Redis cache technology in enterprise one-card system.”Electron. Technol. Softw. Eng.24, no. 2 (2019): 133-134

    2019

  27. [27]

    ”Forensic recovery of SQL server database: Practical approach.”IEEE Access9 (2021): 14564-14575

    Choi, Hoyong, Sangjin Lee, and Doowon Jeong. ”Forensic recovery of SQL server database: Practical approach.”IEEE Access9 (2021): 14564-14575

    2021

  28. [28]

    ”Re-formulated snowflake optimization algorithm (SFO-R).” Evolutionary Intelligence17, no

    Toz, Metin, and G¨ uliz Toz. ”Re-formulated snowflake optimization algorithm (SFO-R).” Evolutionary Intelligence17, no. 3 (2024): 1889-1908

    2024

  29. [29]

    ”Query optimization in mysql database using index.”International Journal of Cyber and IT Service Management2, no

    Maesaroh, Siti, Heru Gunawan, Agung Lestari, Muhammad Sufyan Ats Tsaurie, and Mohamad Fauji. ”Query optimization in mysql database using index.”International Journal of Cyber and IT Service Management2, no. 2 (2022): 104-110

    2022

  30. [30]

    ”Op- timizing bloom filter: Challenges, solutions, and comparisons.”IEEE Communications Surveys & Tutorials21, no

    Luo, Lailong, Deke Guo, Richard TB Ma, Ori Rottenstreich, and Xueshan Luo. ”Op- timizing bloom filter: Challenges, solutions, and comparisons.”IEEE Communications Surveys & Tutorials21, no. 2 (2018): 1912-1949

    2018

  31. [31]

    Alsuhibany

    Alsuhaibani, Mohammed, Rehan Ullah Khan, Ali Mustafa Qamar, and Suliman A. Alsuhibany. ”Content-Based Approach for Improving Bloom Filter Efficiency.”Applied Sciences13, no. 13 (2023): 7922

    2023

  32. [32]

    ”Research on performance optimization of web application system based on JA V A EE.” InJournal of Physics: Conference Series, vol

    Cai, Zengyu, and Jingxiao Li. ”Research on performance optimization of web application system based on JA V A EE.” InJournal of Physics: Conference Series, vol. 1437, no. 1, p. 012039. IOP Publishing, 2020

    2020

  33. [33]

    ”Microservice-oriented plat- form for internet of big data analytics: A proof of concept.”Sensors19, no

    Li, Zheng, Diego Seco, and Alexis Eloy S´ anchez Rodr ´ ıguez. ”Microservice-oriented plat- form for internet of big data analytics: A proof of concept.”Sensors19, no. 5 (2019): 1134

    2019

  34. [34]

    ”Application and realization of key technologies in China railway e-ticketing system.”Railway Sciences 2, no

    Shan, Xinghua, Zhiqiang Zhang, Fei Ning, Shida Li, and Linlin Dai. ”Application and realization of key technologies in China railway e-ticketing system.”Railway Sciences 2, no. 1 (2023): 140-156

    2023

  35. [35]

    Iqbal, M

    Abbas, I., H. Iqbal, M. Ahmad, A. Naveed, and B. Qudoos. ”Comparative study of Zhiyong Zhang et al.: Preprint Submitted to Arxiv.31 technologies and intelligent train ticketing system.”Indian Journal of Science and Tech- nology13, no. 15 (2020): 1570-1579

    2020

  36. [36]

    ”AtomGraph: Tack- ling Atomicity Violation in Smart Contracts using Multimodal GCNs.”arXiv preprint arXiv:2512.02399(2025)

    Li, Xiaoqi, Zongwei Li, Wenkai Li, Zeng Zhang, and Lei Xie. ”AtomGraph: Tack- ling Atomicity Violation in Smart Contracts using Multimodal GCNs.”arXiv preprint arXiv:2512.02399(2025)

    arXiv 2025

  37. [37]

    ”Implementation and Security Analysis of Cryptocurrencies Based on Ethereum.”arXiv preprint arXiv:2504.21367(2025)

    Gao, Pengfei, Dechao Kong, and Xiaoqi Li. ”Implementation and Security Analysis of Cryptocurrencies Based on Ethereum.”arXiv preprint arXiv:2504.21367(2025)

    Pith/arXiv arXiv 2025

  38. [38]

    ”A Multi-Layered Security Analysis of Blockchain Systems: From Attack Vectors to Defense and System Hardening.”arXiv preprint arXiv:2504.09181(2025)

    Yang, Yuhuan, Shipeng Ye, and Xiaoqi Li. ”A Multi-Layered Security Analysis of Blockchain Systems: From Attack Vectors to Defense and System Hardening.”arXiv preprint arXiv:2504.09181(2025)

    Pith/arXiv arXiv 2025

  39. [39]

    ”Security Vulnerabilities in Ethereum Smart Con- tracts: A Systematic Analysis.”arXiv preprint arXiv:2504.05968(2025)

    Wu, Jixuan, Lei Xie, and Xiaoqi Li. ”Security Vulnerabilities in Ethereum Smart Con- tracts: A Systematic Analysis.”arXiv preprint arXiv:2504.05968(2025)

    arXiv 2025

  40. [40]

    ”2PC*: a distributed transaction concurrency control protocol of multi-microservice based on cloud computing platform.”Journal of Cloud Computing9, no

    Fan, Pan, Jing Liu, Wei Yin, Hui Wang, Xiaohong Chen, and Haiying Sun. ”2PC*: a distributed transaction concurrency control protocol of multi-microservice based on cloud computing platform.”Journal of Cloud Computing9, no. 1 (2020): 40

    2020

  41. [41]

    ”Research On Optimization Model of High Availability and Flexibility of Blockchain System Based on Microservice Architecture.”Procedia Computer Science 261 (2025): 207-216

    Li, Jin. ”Research On Optimization Model of High Availability and Flexibility of Blockchain System Based on Microservice Architecture.”Procedia Computer Science 261 (2025): 207-216

    2025

  42. [42]

    ”CKG-LLM: LLM- Assisted Detection of Smart Contract Access Control Vulnerabilities Based on Knowl- edge Graphs.”arXiv preprint arXiv:2512.06846(2025)

    Li, Xiaoqi, Hailu Kuang, Wenkai Li, Zongwei Li, and Shipeng Ye. ”CKG-LLM: LLM- Assisted Detection of Smart Contract Access Control Vulnerabilities Based on Knowl- edge Graphs.”arXiv preprint arXiv:2512.06846(2025)

    Pith/arXiv arXiv 2025

  43. [43]

    ”Based on netease train ticket booking system design and implemen- tation.” InJournal of Physics: Conference Series, vol

    Cheng, Yunli. ”Based on netease train ticket booking system design and implemen- tation.” InJournal of Physics: Conference Series, vol. 1486, no. 2, p. 022006. IOP Publishing, 2020

    2020

  44. [44]

    ”Penetrating the hostile: Detecting defi protocol exploits through cross-contract analysis.”IEEE Transactions on Information Forensics and Security20 (2025): 11759-11774

    Li, Xiaoqi, Wenkai Li, Zhiquan Liu, Yuqing Zhang, and Yingjie Mao. ”Penetrating the hostile: Detecting defi protocol exploits through cross-contract analysis.”IEEE Transactions on Information Forensics and Security20 (2025): 11759-11774

    2025

  45. [45]

    ” O’Reilly Me- dia, Inc.”, 2021

    Newman, Sam.Building microservices: designing fine-grained systems. ” O’Reilly Me- dia, Inc.”, 2021

    2021

  46. [46]

    ”Facial Recognition Leveraging Generative Adversarial Networks.”arXiv preprint arXiv:2505.11884(2025)

    Li, Zhongwen, Zongwei Li, and Xiaoqi Li. ”Facial Recognition Leveraging Generative Adversarial Networks.”arXiv preprint arXiv:2505.11884(2025)

    arXiv 2025

  47. [47]

    Alboqmi, Rami, and Rose F. Gamble. ”Enhancing microservice security through vulnerability-driven trust in the service mesh architecture.”Sensors25, no. 3 (2025): 914. Zhiyong Zhang et al.: Preprint Submitted to Arxiv.32

    2025

  48. [48]

    Chen, Yihao, Eduardo Fernandes, Bram Adams, and Ahmed E. Hassan. ”On practition- ers’ concerns when adopting service mesh frameworks.”Empirical software engineering 28, no. 5 (2023): 113

    2023

  49. [49]

    ”USCSA: Evolution-Aware Se- curity Analysis for Proxy-Based Upgradeable Smart Contracts.”arXiv preprint arXiv:2512.08372(2025)

    Li, Xiaoqi, Lei Xie, Wenkai Li, and Zongwei Li. ”USCSA: Evolution-Aware Se- curity Analysis for Proxy-Based Upgradeable Smart Contracts.”arXiv preprint arXiv:2512.08372(2025)

    arXiv 2025

  50. [50]

    ”Enhancing monitoring performance: A microservices ap- proach to monitoring with spyware techniques and prediction models.”Sensors24, no

    Rossetto, Anubis Graciela de Moraes, Darlan Noetzold, Luis Augusto Silva, and Valderi Reis Quietinho Leithardt. ”Enhancing monitoring performance: A microservices ap- proach to monitoring with spyware techniques and prediction models.”Sensors24, no. 13 (2024): 4212

    2024

  51. [51]

    ”Comparison of representative microservices technologies in terms of per- formance for use for projects based on sensor networks.”Sensors22, no

    Plecinski, Piotr, Nataliia Bokla, Tamara Klymkovych, Mykhailo Melnyk, and Wojciech Zabierowski. ”Comparison of representative microservices technologies in terms of per- formance for use for projects based on sensor networks.”Sensors22, no. 20 (2022): 7759

    2022

  52. [52]

    ”From Fomo3D to Lottery DAPP: Analysis of Ethereum-Based Gambling Applications.”arXiv preprint arXiv:2508.12303(2025)

    Long, Xu, Yishun Wang, and Xiaoqi Li. ”From Fomo3D to Lottery DAPP: Analysis of Ethereum-Based Gambling Applications.”arXiv preprint arXiv:2508.12303(2025)

    arXiv 2025

  53. [53]

    ”Redis vs

    Kanthed, Surbhi. ”Redis vs. Memcached in Microservices Architectures: Caching Strate- gies.” (2023)

    2023

  54. [54]

    ”DoS Attacks and Defense Technologies in Blockchain Systems: A Hierarchical Analysis.”arXiv preprint arXiv:2507.22611(2025)

    Zhang, Chunyi, Fengjiao Dou, and Xiaoqi Li. ”DoS Attacks and Defense Technologies in Blockchain Systems: A Hierarchical Analysis.”arXiv preprint arXiv:2507.22611(2025)

    arXiv 2025

  55. [55]

    ”RAPO: An Automated Performance Optimization Tool for Redis Clusters in Distributed Storage Metadata Management.”IEEE Access(2025)

    Zhu, Yunkai, Tian Xia, Te Zhu, Zhoujie Zhao, Kexin Li, and Xingbo Hu. ”RAPO: An Automated Performance Optimization Tool for Redis Clusters in Distributed Storage Metadata Management.”IEEE Access(2025)

    2025

  56. [56]

    ”A Comprehensive Study of Ex- ploitable Patterns in Smart Contracts: From Vulnerability to Defense.”arXiv preprint arXiv:2504.21480(2025)

    Ding, Yuchen, Hongli Peng, and Xiaoqi Li. ”A Comprehensive Study of Ex- ploitable Patterns in Smart Contracts: From Vulnerability to Defense.”arXiv preprint arXiv:2504.21480(2025)

    Pith/arXiv arXiv 2025

  57. [57]

    ”Recovery techniques for database systems.”ACM Computing Surveys (CSUR)10, no

    Verhofstad, Joost SM. ”Recovery techniques for database systems.”ACM Computing Surveys (CSUR)10, no. 2 (1978): 167-195

    1978

  58. [58]

    ”An Empirical Analysis of EOS Blockchain: Architecture, Contract, and Security.”arXiv preprint arXiv:2505.15051(2025)

    Liu, Haiyang, Yingjie Mao, and Xiaoqi Li. ”An Empirical Analysis of EOS Blockchain: Architecture, Contract, and Security.”arXiv preprint arXiv:2505.15051(2025)

    Pith/arXiv arXiv 2025

  59. [59]

    ”Main memory database recovery: A survey.”ACM Computing Surveys (CSUR)54, no

    Magalhaes, Arlino, Jose Maria Monteiro, and Angelo Brayner. ”Main memory database recovery: A survey.”ACM Computing Surveys (CSUR)54, no. 2 (2021): 1-36

    2021

  60. [60]

    ”From Data Behavior to Code Analysis: A Multimodal Study on Security and Privacy Challenges in Blockchain-Based DApp.” arXiv preprint arXiv:2504.11860(2025)

    Sun, Haoyang, Yishun Wang, and Xiaoqi Li. ”From Data Behavior to Code Analysis: A Multimodal Study on Security and Privacy Challenges in Blockchain-Based DApp.” arXiv preprint arXiv:2504.11860(2025). Zhiyong Zhang et al.: Preprint Submitted to Arxiv.33

    arXiv 2025

  61. [61]

    ”Performance comparison between two relational database manage- ment systems: B-tree indexing in PostgreSQL and MySQL.” (2024)

    Lindgren, Simon. ”Performance comparison between two relational database manage- ment systems: B-tree indexing in PostgreSQL and MySQL.” (2024)

    2024

  62. [62]

    ”Beyond the Hype: A Large-Scale Empirical Analysis of On-Chain Transactions in NFT Scams.”arXiv preprint arXiv:2512.01577(2025)

    Li, Wenkai, Zongwei Li, Xiaoqi Li, Chunyi Zhang, Xiaoyan Zhang, and Yuqing Zhang. ”Beyond the Hype: A Large-Scale Empirical Analysis of On-Chain Transactions in NFT Scams.”arXiv preprint arXiv:2512.01577(2025)

    arXiv 2025

  63. [63]

    ”A tale of tails: Model collapse as a change of scaling laws.”arXiv preprint arXiv:2402.07043 (2024)

    Dohmatob, Elvis, Yunzhen Feng, Pu Yang, Francois Charton, and Julia Kempe. ”A tale of tails: Model collapse as a change of scaling laws.”arXiv preprint arXiv:2402.07043 (2024)

    Pith/arXiv arXiv 2024

  64. [64]

    ”Intelligent Transaction Scheduling to Enhance Concurrency in High-Contention Workloads.”Applied Sciences15, no

    Chen, Shuhan, Congqi Shen, and Chunming Wu. ”Intelligent Transaction Scheduling to Enhance Concurrency in High-Contention Workloads.”Applied Sciences15, no. 11 (2025): 6341

    2025

  65. [65]

    Liu, Yang, Fanyou Wu, Cheng Lyu, Shen Li, Jieping Ye, and Xiaobo Qu. ”Deep dis- patching: A deep reinforcement learning approach for vehicle dispatching on online ride-hailing platform.”Transportation Research Part E: Logistics and Transportation Review161 (2022): 102694

    2022

  66. [66]

    ”Security analysis of ponzi schemes in ethereum smart contracts.”arXiv preprint arXiv:2510.03819(2025)

    Zhang, Chunyi, Qinghong Wei, and Xiaoqi Li. ”Security analysis of ponzi schemes in ethereum smart contracts.”arXiv preprint arXiv:2510.03819(2025)

    arXiv 2025

  67. [67]

    Cloud, Edge, and End Collaboration

    Long, Yun, Yude Bao, and Linjun Zeng. ”Research on Edge-Computing-Based High Concurrency and Availability “Cloud, Edge, and End Collaboration” Substation Oper- ation Support System and Applications.”Energies17, no. 1 (2023): 194

    2023

  68. [68]

    ”A trend detection-based auto- scaling method for containers in high-concurrency scenarios.”Ieee Access12 (2024): 71821-71834

    Liu, Haipeng, Wenhao Zhu, Siyi Fu, and Yongjun Lu. ”A trend detection-based auto- scaling method for containers in high-concurrency scenarios.”Ieee Access12 (2024): 71821-71834

    2024

  69. [69]

    ”Research on the optimization of A/B testing system based on dynamic strategy distribution.”Processes11, no

    Sheng, Jinfang, Huadan Liu, and Bin Wang. ”Research on the optimization of A/B testing system based on dynamic strategy distribution.”Processes11, no. 3 (2023): 912

    2023

  70. [70]

    ”PoolRunner: An Exten- sible Performance Testing Simulation Tool for Thread-Pool Middleware.”IEEE Access (2025)

    Bahadur, Faisal, Zulfiqar Ahmad, and Abdulmohsen Algarni. ”PoolRunner: An Exten- sible Performance Testing Simulation Tool for Thread-Pool Middleware.”IEEE Access (2025)

    2025

  71. [71]

    Beroni´ c, Dora, Paula Pufek, Branko Mihaljevi´ c, and Aleksander Radovan. ”On Ana- lyzing Virtual Threads–a Structured Concurrency Model for Scalable Applications on the JVM.” In2021 44th International Convention on Information, Communication and Electronic Technology (MIPRO), pp. 1684-1689. IEEE, 2021

    2021

  72. [72]

    ”Comparative analysis of metaheuristic load balancing algorithms for efficient load balancing in cloud computing.”Journal of cloud computing12, no

    Zhou, Jincheng, Umesh Kumar Lilhore, Tao Hai, Sarita Simaiya, Dayang Norhayati Abang Jawawi, Deema Mohammed Alsekait, Sachin Ahuja, Cresantus Biamba, and Zhiyong Zhang et al.: Preprint Submitted to Arxiv.34 Mounir Hamdi. ”Comparative analysis of metaheuristic load balancing algorithms for efficient load balancing in cloud computing.”Journal of cloud compu...

    2023

  73. [73]

    ”Comparative Analysis of Blockchain Systems.”arXiv preprint arXiv:2505.08652(2025)

    Huang, Jiaqi, Yuanzheng Niu, Xiaoqi Li, and Zongwei Li. ”Comparative Analysis of Blockchain Systems.”arXiv preprint arXiv:2505.08652(2025)

    Pith/arXiv arXiv 2025

  74. [74]

    ”A comprehensive study of load balancing approaches in the cloud computing environment and a novel fault tolerance approach.”IEEE access 8 (2020): 130500-130526

    Shahid, Muhammad Asim, Noman Islam, Muhammad Mansoor Alam, Mazliham Mohd Su’ud, and Shahrulniza Musa. ”A comprehensive study of load balancing approaches in the cloud computing environment and a novel fault tolerance approach.”IEEE access 8 (2020): 130500-130526

    2020

  75. [75]

    Elmagzoub, Ghulam Muhammad, and Kashif Hussain Talpur

    Al Reshan, Mana Saleh, Darakhshan Syed, Noman Islam, Asadullah Shaikh, Mo- hammed Hamdi, Mohamed A. Elmagzoub, Ghulam Muhammad, and Kashif Hussain Talpur. ”A fast converging and globally optimized approach for load balancing in cloud computing.”IEEE Access11 (2023): 11390-11404

    2023

  76. [76]

    Shafiq, Dalia Abdulkareem, Noor Zaman Jhanjhi, Azween Abdullah, and Mohammed A. Alzain. ”A load balancing algorithm for the data centres to optimize cloud computing applications.”IEEE access9 (2021): 41731-41744

    2021

  77. [77]

    ”CMODLB: an efficient load balancing approach in cloud computing environment.”The Journal of Supercomputing77, no

    Negi, Sarita, Man Mohan Singh Rauthan, Kunwar Singh Vaisla, and Neelam Panwar. ”CMODLB: an efficient load balancing approach in cloud computing environment.”The Journal of Supercomputing77, no. 8 (2021): 8787-8839. Zhiyong Zhang et al.: Preprint Submitted to Arxiv.35

    2021

This paper was first reviewed by deepseek-v4-flash on August 3, 2026.