Building a Scalable, Flexible Operation Configuration Platform for Mobile Apps

Background

Mobile applications often need to update UI elements such as top navigation, user pages, and pop‑up dialogs across many dimensions (mode, version, platform, language, channel). Frequent changes make it hard to allocate operation resources efficiently, stably, and flexibly.

Enable rapid configuration of operation resources.

Support new operation requirements with minimal development effort.

Configuration Resource Decomposition

Operation‑related data is split into two categories:

Operation resources – highly dynamic items (e.g., time‑limited pop‑up ads) that vary by mode, language, and version.

Base data – relatively static items (e.g., bottom navigation bar) that change infrequently but still require multi‑dimensional support.

Practical Pain Points

Low Operational Efficiency

Each new operation request previously required a full development cycle: requirement review → UI page development → configuration management → deployment. This caused high development cost, long cycles, and poor flexibility because all dimensions had to be predefined.

Separate configuration page per request (1‑2 days of work).

Long lead time from request to production.

Inability to adjust dimensions dynamically.

Repetitive Development

Common backend features such as operation logs, audit mechanisms, and mode‑based data filtering were re‑implemented for every new configuration demand.

Design Principles and Reflections

All data must be configurable.

Operation data must be highly available.

APIs must be high‑performance.

JSON‑Based Configuration

Store configuration as JSON so that new fields (title, subtitle, image, link, etc.) can be added without code changes. The backend provides a field‑management UI to handle dynamic extensions.

Multi‑Point Data Storage

Persist data in three layers: a distributed cache (Redis cluster), a relational/NoSQL database, and an optional local cache on the business side. This guarantees data availability even when one layer fails.

SDK Integration

Provide a Maven package that exposes OppkitClient. Developers inject the client and call OppkitRequest to obtain filtered and translated data, eliminating direct dependence on centralized services.

// Maven dependency
<dependency>
    <groupId>com.company.oppkit</groupId>
    <artifactId>oppkit-sdk</artifactId>
    <version>1.0.0</version>
</dependency>

// Usage example
OppkitClient client = new OppkitClient();
OppkitRequest request = new OppkitRequest()
        .setMode("OVERSEAS")
        .setLanguage("en")
        .setVersion("2.3.1");
String json = client.fetch(request);

SDK Request Flow

Operation Slot Architecture

The system is organized into four layers: Data, Service, Access, and Monitoring.

Data Layer

All operation data is stored here. To handle large volume and high QPS, a Redis cluster is used for caching, and asynchronous updates are propagated via message queues.

Service Layer

Operation backend – UI for product and operation teams to configure data.

Open platform – API for developers to create new operation slots.

Data service – Unified, high‑availability, high‑performance API for data retrieval.

SDK – Simplifies integration and improves performance.

Access Layer

C‑Side Integration : Developers add the SDK, inject OppkitClient, and call it to receive filtered, translated data.

B‑Side Configuration : All aspects are configurable via the open platform. Each slot can contain multiple fields (e.g., title, link) with language‑specific keys.

Monitoring Layer

Monitors the data layer, service layer, and SDK local‑cache usage. The SDK decides whether to use the local cache based on request characteristics (e.g., device ID, high‑frequency fields) and falls back to a direct service call when needed.

Stability and Performance

Overall Request Flow

SDK Local Cache Strategy

Benefits

Reduces traffic to central services.

Minimizes latency for overseas users.

Provides data fallback without redeploying business services.

Drawbacks

Cache updates are not real‑time, so business services may see stale data.

Three cache architectures were evaluated:

Simple architecture – easy to implement but poor concurrency and stability.

Local‑cache‑only – reduces central load but introduces data inconsistency.

OPPKIT‑SDK with asynchronous message listening – balances load reduction and data freshness.

Performance Guarantees

Operation data changes infrequently, so local caching dramatically improves backend performance. Each slot carries a version timestamp; the client compares timestamps and only fetches updates when necessary, avoiding unnecessary network calls.

Request Flow Diagram

Summary

The operation‑slot platform addresses low efficiency and repetitive development by:

Using JSON‑based configuration for extensibility.

Supporting a multi‑language data model for operation resources.

Providing an SDK that implements local caching, MQ‑driven asynchronous updates, and graceful fallback, ensuring high availability and performance, especially in overseas scenarios.