Switchquery Configuration Platform: Real‑Time Mobile Feature‑Flag Delivery Architecture and Implementation

Background – With the rapid growth of mobile internet, developers need a fast, reliable way to toggle features, perform gray releases, and roll back problematic functions. Switchquery was built as a configuration platform that delivers configuration changes to apps within seconds, improving reachability and centralized management.

Technical Principles – The platform evaluates three common delivery methods (push notifications, long‑lived TCP/WebSocket connections, and polling) and discards them due to low reachability, high resource consumption, or unnecessary traffic. Instead, Switchquery uses a novel approach: a CMS stores configuration versions, a unified gateway injects the version into every HTTP response header (x‑switch‑config), and the client component compares this version with its cache to decide whether to fetch new configuration data.

Real‑time Delivery Scheme – When a user updates a configuration in the CMS, the new version number is written to the gateway. All subsequent client requests receive the version in the response header; if the version is newer, the client pulls the configuration JSON from the Switchquery API or CDN (fallback). This method avoids push permission issues, eliminates long‑connection overhead, and provides low‑cost, high‑speed updates.

Process Architecture Design – The architecture includes: (1) CMS for defining boolean, integer, and string flags with versioning, platform, and device filters; (2) Unified gateway that records version numbers and adds the x‑switch‑config header; (3) Client network layer that parses the header, emits a global notification, and triggers the configuration component; (4) Configuration component that validates the version, optionally waits a random delay (randomtime), and fetches the latest config, caching it locally and falling back to CDN on failures.

Integration Flow – The article outlines step‑by‑step integration for Android and iOS, providing sample API calls:

// Get boolean flag, returns defValue if fetch fails
SwitchQueryFetcher.getSwitchBooleanValue(String switchName, boolean defValue);
// Get integer flag
SwitchQueryFetcher.getSwitchIntValue(String switchName, int defValue);
// Get string flag
SwitchQueryFetcher.getSwitchStringValue(String switchName, String defValue);

// iOS equivalents
BOOL JDSwitchBoolValue(NSString *key);
NSInteger JDSwitchIntValue(NSString *key);
NSString* JDSwitchStringValue(NSString *key);

CMS Creation & Configuration – Users create business modules in the CMS, define configuration items (ID, platform version range, system version, type, name, rollout ratio, whitelist, value, description), and publish them. The platform supports gray releases, white‑list overrides, and multi‑app scenarios.

Technical Optimizations – To balance real‑time needs and cost, the CMS batches changes within a configurable interval (default 5 s). Clients use a random delay (randomtime) before pulling new configs to smooth traffic spikes. Configuration data is stored in memory and also cached as JSON on CDN for fallback during outages.

Benefits & Case Studies – In the 2022 Spring Festival “X” project, Switchquery reduced startup API calls from 110 to 8, achieving 100 % downgrade success with zero incidents. During the 2022 Double‑Eleven promotion, 38 business modules and 392 switches achieved a 98.3 % reach rate, with a 58.8 % reduction in peak QPS, ensuring stable operation.

Conclusion – Switchquery aims to extend its real‑time configuration capabilities to more apps and modules, adding features such as operation logs, device filtering, and dynamic whitelist management via QR‑code scanning, thereby providing a high‑performance, second‑level configuration solution for mobile ecosystems.