How Meituan Built a Scalable Data Security Platform with a Plug‑in Permission Model

Background

Frequent data‑security incidents have highlighted the need for fine‑grained permission control over internal data products such as analytics, data services, and governance tools. Traditional access‑control models (ACL, RBAC) only provide function‑level control and cannot express the complex relationships of data‑level resources.

Limitations of Existing Models

ACL directly links users to resources, making bulk permission assignments cumbersome. RBAC introduces roles but lacks role‑to‑role relationships, which hampers permission inheritance in hierarchical organizations. Both models struggle to represent multi‑level resource hierarchies (e.g., reports, tabs, components, dimensions, metrics) and their source tables.

New Permission Model Design

Meituan designed a model that treats resources as a tree with parent‑child relationships and allows roles to inherit from other roles. The model is split into three parts: a user center, a resource center, and a permission center, each supporting pre‑, during‑, and post‑operation scenarios (approval, permission, audit).

User Center

Manages users and roles; a user can hold multiple roles (personal, organizational, custom).

Roles support multi‑level inheritance, enabling a user in a sub‑role to automatically acquire permissions of all ancestor roles.

User and department data are synchronized in real time via Meituan's Kafka‑based middleware (Mafka) and ETL jobs.

Resource Center

Supports custom resource types on top of generic types, enabling unified control of diverse system assets.

Resources are hierarchical; a tree view simplifies bulk permission assignment (e.g., granting a report also grants its child dimensions and metrics).

Resources can be packaged to streamline the granting process.

Each resource carries a security level and owner, allowing different approval templates for self‑service permission requests.

Permission Center

Scope strategy: grant partial or full access to specific dimension values within a report.

Expression strategy: attach SQL‑like limits (e.g., limit 10) to further restrict results.

Automatic permission merging: combine permissions from multiple roles, using a “nearest‑rule” precedence when conflicts arise.

Blacklist/whitelist: highest‑priority rules that can explicitly allow or deny access to a resource.

Challenges

Supporting an expanding set of business lines while keeping the platform flexible and extensible.

Providing a generic data‑security platform that satisfies most security requirements.

Ensuring high availability for a high‑QPS permission system.

Solution Approach

Introduce a plug‑in service layer that extends the generic permission core for line‑specific needs.

Offer a unified platform covering basic permission, approval, and audit functions.

Adopt a microservice architecture that separates core and non‑core services and uses data caching and degradation to guarantee availability.

Overall Architecture

The platform consists of three blocks: data‑content permission, approval flow, and audit log services. Plug‑in services are built on top of generic services via SDKs, allowing independent deployment and custom rule implementation.

Permission Inheritance & Storage

Resources support multi‑level hierarchy; granting a parent resource automatically grants all descendant resources. Only the relationship between the user and the ancestor resource is stored, dramatically reducing the size of the permission matrix.

Permission data is versioned similarly to HBase or MySQL binlog. The latest permission resides in MySQL/Redis, while historical versions are stored in Elasticsearch for audit and recovery.

High‑Availability Measures

Microservice separation of core and non‑core services; each service can be independently scaled.

Front‑end access via HTTP, authenticated by BA, load‑balanced by Nginx.

Service layer composed of independent microservices deployed per demand.

Client layer exposes a unified RPC framework (Pigeon) via Maven dependencies.

Read/write splitting using Meituan's Zebra middleware; Redis caches hot data with fallback to MySQL.

Elasticsearch stores audit logs and inactive data.

Circuit‑breaker and degradation mechanisms protect core services during outages.

Asynchronous Processing & Reliability

Message queues handle user requests, returning immediate success while processing asynchronously.

Crane schedules periodic tasks such as permission expiration scans.

Thread pools process approval callbacks and retries, reducing thread churn.

Distributed locks ensure single‑thread execution for critical sections, preventing duplicate submissions.

Future Outlook

Meituan plans to publish a unified plug‑in development specification, enabling downstream systems to extend the platform with custom permission logic. A generic rule‑engine service will be extracted to allow flexible, configurable rule processing, further strengthening centralized data‑product permission management.