Improving TAPD Integration Performance and Reliability through Proxy, Local Data Storage, and Rate Limiting

In the company's product development system, TAPD is used to manage requirements, bugs, and tasks, and many DevOps operations interact with TAPD via its API, such as branch creation, deployment, and status updates. Frequent TAPD service fluctuations affect the DevOps workflow, leading to latency, security risks, and occasional rate‑limiting.

The identified problems include slow cross‑company HTTP calls, credential leakage due to multiple services reading/writing TAPD data, and overall TAPD service throttling caused by high request volume from various business lines.

To solve these issues, the team introduced a proxy that forwards all TAPD API calls through a unified service, as shown in the first diagram. They also considered storing TAPD data locally so that queries could be performed against an internal database, reducing external API calls.

Using TAPD's webhook capability, the system subscribes to changes in requirements, bugs, and tasks, persisting the data in a local database. This transforms remote calls into fast local interface accesses, improving performance and response time. The data flow is: TAPD sends webhook notifications → internal service publishes to MQ → a listener processes messages and stores the relevant entities and change logs.

New challenges introduced by this architecture include handling rate limiting, ensuring data consistency, and dealing with data that cannot be captured via webhook. The team built a custom rate‑limiter annotated with @Ratelimiter , allowing configuration of key, limit, and expiration time for each protected method. Example usage limits a specific query to three requests per second.

When TAPD enforces its own rate limits (e.g., 10 requests per second for change history), the system queues change events in Redis, processes them asynchronously, and applies the custom rate‑limiter to the query operations. If throttling occurs, data is enqueued and later consumed once the limit is lifted.

Additional reliability measures include sending alert messages via corporate WeChat when data ingestion fails, and scheduling nightly batch jobs to synchronize data that cannot be captured through webhooks, such as project information and user‑project relationships.

The final outcome is a more performant and stable TAPD integration: the proxy and local data storage reduce latency and API traffic, the rate‑limiter prevents service disruptions, and the overall solution ensures data stability across multiple business lines while providing a solid foundation for future metrics collection.