# SDS vs Sentinel: How to Choose the Right Flow-Control and Downgrade Solution > Understand SDS vs Sentinel flow control and downgrade solutions. SDS offers basic per-instance rules while Sentinel provides cluster-wide, system-level protection. Choose the right fit for your needs. - Repository: [DiDi/sds](https://github.com/didi/sds) - Tags: comparison - Published: 2026-02-28 --- **SDS provides a lightweight, Java-only client-server model ideal for simple per-instance downgrade rules, while Sentinel offers cluster-wide flow control, system-level protection, and deep integration with the Alibaba ecosystem.** Choosing between flow-control libraries can significantly impact your microservices resilience strategy. This guide compares **SDS** (Service Downgrade System, open-sourced by DiDi) and **Sentinel** (Alibaba's mainstream solution) based on actual source code analysis of the `didi/sds` repository. Understanding the architectural and functional differences between SDS and Sentinel helps you select the right downgrade mechanism for your Java applications. ## Architecture and Deployment Models ### SDS Client-Server Design SDS follows a **C/S model** where a lightweight `sds-client` jar runs inside your business process. According to the repository's [`README.md`](https://github.com/didi/sds/blob/main/README.md), the client periodically (every 10 seconds) sends a heartbeat carrying statistics and receives the latest downgrade rules from the `sds-admin` server. All aggregation and rule storage lives on the admin side, while the client maintains only in-memory counters. This design keeps the client footprint minimal but introduces a network dependency for rule synchronization. ### Sentinel Embedded Library Approach Sentinel operates as an **embedded library** with an optional central Dashboard. Each instance holds its own flow-control rules in-process and optionally synchronizes with a Nacos or ZooKeeper cluster for rule sharing. The Dashboard polls instances via HTTP to fetch metrics, giving you real-time visibility without requiring a persistent server connection for rule evaluation. ## Feature Comparison: Control Types and Granularity ### Supported Downgrade Strategies SDS supports five control types configurable per-point in the admin UI: - **Visit (QPS)** – Fixed-time-window access counting - **Concurrent** – Semaphore-based limiting - **Exception / ExceptionRate** – Error counting and ratio thresholds - **Timeout** – Latency threshold violations - **TokenBucket** – Token-bucket algorithm implementation These strategies are implemented in the strategy executor classes like `VisitStrategyExecutor` located in `sds-client/src/main/java/com/didiglobal/sds/client/strategy/executor/`. Sentinel provides **Flow** control (QPS/thread-count with warm-up), **Concurrency** limiting, **Degrade** (exception-ratio, RT, error-count), **System** protection (CPU, load metrics), and **Authority** controls (black/white lists). Rules are stored in memory and can be hot-reloaded from the Dashboard. ### Cluster-Wide Quotas vs Per-Instance Limits A critical differentiator is **cluster-wide limit support**. As implemented in `didi/sds`, SDS does not support unified quotas across clusters—each client's counters remain isolated in memory, making it suitable for single-node or small-scale deployments where per-instance limits suffice. The repository explicitly notes this limitation in the README. In contrast, Sentinel supports cluster-level flow control through shared rule stores (Nacos/ZooKeeper), allowing you to enforce the same QPS cap across all instances simultaneously. ## Developer Experience and Integration ### SDS Lightweight Java Client SDS prioritizes simplicity with minimal external dependencies. You initialize a singleton `SdsClient` via `SdsClientFactory` and check `shouldDowngrade(point)` before executing business logic. For even faster integration, the `SdsEasyUtil` class in [`sds-easy/src/main/java/com/didiglobal/sds/easy/SdsEasyUtil.java`](https://github.com/didi/sds/blob/main/sds-easy/src/main/java/com/didiglobal/sds/easy/SdsEasyUtil.java) provides one-liner downgrade wrapping. ### Sentinel Ecosystem Integration Sentinel requires slightly more setup but offers richer integrations. You define `FlowRule` objects programmatically or through the Dashboard UI, with native support for Spring Cloud, Dubbo, and Spring Cloud Alibaba. This makes Sentinel the natural choice if you already operate within the Alibaba cloud stack. ## Code Implementation Examples ### Basic SDS Usage with SdsClient The core API involves three steps: initialization, downgrade checking, and cleanup signaling. ```java // Initialize once (singleton) private static final String SERVER_URL = "http://127.0.0.1:8887"; private static final SdsClient sdsClient = SdsClientFactory.getOrCreateSdsClient("BikeBusinessDept", "order", SERVER_URL); // Business method with manual checks public boolean createOrder() { final String POINT = "createOrderPoint"; try { if (sdsClient.shouldDowngrade(POINT)) { // Downgraded path – return default or throw return false; } // Normal logic … return true; } catch (Exception e) { sdsClient.exceptionSign(POINT, e); throw e; } finally { sdsClient.downgradeFinally(POINT); } } ``` Key files: `SdsClientFactory` and the `SdsClient` interface in `sds-client/src/main/java/com/didiglobal/sds/client/`. ### Simplified SDS Integration with SdsEasyUtil For scenarios requiring less boilerplate, use the utility wrapper: ```java String result = SdsEasyUtil.invokerMethod( "somePoint", "fallbackResult", // fallback value when downgraded () -> { // business logic return remoteService.call(); }); ``` ### Sentinel Flow Control Implementation Sentinel uses a slot-chain mechanism with entry/exit patterns: ```java // Define a rule (once at startup) List rules = new ArrayList<>(); FlowRule rule = new FlowRule("createOrder") .setCount(100) // QPS limit .setGrade(RuleConstant.FLOW_GRADE_QPS); rules.add(rule); FlowRuleManager.loadRules(rules); // Business method public boolean createOrder() { Entry entry = null; try { entry = SphU.entry("createOrder"); // protected logic return remoteService.call(); } catch (BlockException e) { // downgraded path return false; } finally { if (entry != null) { entry.exit(); } } } ``` ## When to Choose SDS vs Sentinel Select **SDS** when you need a lightweight client with no external dependencies, run single-node or small-scale clusters where per-instance limits are sufficient, and prefer a one-click downgrade with a simple admin UI. The `sds-admin` console provides real-time charts for each point, making it ideal for rapid deployment scenarios. Choose **Sentinel** when you require cluster-wide flow control, need to share rules across many instances, already use the Alibaba ecosystem (Nacos, Dubbo, Spring Cloud Alibaba), or need system-level protection based on CPU and load metrics. Sentinel's larger community and frequent releases also provide long-term maintenance advantages. ## Summary - SDS operates on a **client-server model** with a lightweight Java client sending heartbeats to an admin server, while Sentinel uses an **embedded library** approach with optional cluster synchronization. - SDS supports **per-instance limits only**, making it suitable for smaller deployments, whereas Sentinel offers **cluster-wide quotas** through shared rule stores. - SDS provides **five specific downgrade strategies** (Visit, Concurrent, Exception, Timeout, TokenBucket) through executors like `VisitStrategyExecutor`, while Sentinel offers **broader protection types** including system-level metrics. - SDS excels in **simplicity and minimal footprint** with classes like `SdsEasyUtil` for one-line integration, while Sentinel provides **deep ecosystem integration** with Alibaba's cloud stack. - **Choose SDS** for lightweight, Java-only deployments with simple downgrade needs; **choose Sentinel** for complex, distributed systems requiring cluster coordination. ## Frequently Asked Questions ### Can SDS work with non-Java languages? No. According to the source analysis of the `didi/sds` repository, SDS is a pure Java client with no native support for other runtimes. The `sds-client` jar must run inside your JVM process. If you need multi-language support, Sentinel offers broader language coverage through community extensions. ### Does SDS support cluster-wide rate limiting? No. As implemented in `didi/sds`, SDS does not support cluster-wide limits. Each client maintains isolated in-memory counters, and there is no unified quota mechanism across instances. For cluster-level coordination, you must use Sentinel with a shared rule store like Nacos or ZooKeeper. ### Which solution has lower operational overhead? SDS generally has lower operational overhead for small teams. The `sds-admin` server handles all aggregation and storage, and the client requires only a 10-second heartbeat configuration. Sentinel requires managing rule synchronization across instances or setting up Nacos/ZooKeeper for cluster modes, increasing infrastructure complexity. ### Can I migrate from SDS to Sentinel easily? Migration requires code changes but follows similar concepts. Both use string-based resource identifiers (points in SDS, resources in Sentinel) and offer downgrade/fallback mechanisms. However, you must replace `SdsClient.shouldDowngrade()` calls with Sentinel's `SphU.entry()` blocks and convert SDS point configurations to Sentinel rules. The strategy executors in SDS map roughly to Sentinel's slot chain, but rule syntax differs significantly.