Microservicessystem_design~25 mins

Feature toggles in Microservices - System Design Exercise

Choose your learning style9 modes available

Learn Why Deep Arch Practice Challenge Design Recall Scale

Design: Feature Toggle System for Microservices

Design the feature toggle management system and its integration with microservices. Out of scope: detailed UI design for management console, specific microservice business logic.

Functional Requirements

FR1: Allow enabling or disabling features dynamically without redeploying services

FR2: Support gradual rollout of features to a subset of users

FR3: Provide a centralized management interface for toggles

FR4: Ensure low latency toggle checks for microservices

FR5: Support different toggle types: boolean, percentage rollout, user-based targeting

FR6: Allow toggles to be updated in real-time with minimal impact

FR7: Provide audit logs for toggle changes

FR8: Ensure toggle state consistency across distributed services

Non-Functional Requirements

NFR1: Handle 10,000 toggle checks per second with p99 latency under 20ms

NFR2: 99.9% uptime for toggle service

NFR3: Support up to 1000 concurrent toggle updates per minute

NFR4: Microservices must not be tightly coupled to toggle service availability

NFR5: Toggle data size should be optimized for fast retrieval

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

Central toggle configuration service with API

Toggle storage database (fast key-value store)

Cache layer for low latency reads

Management UI for toggle control

Audit logging system

SDK or client library for microservices to query toggles

Message queue or pub/sub for toggle update notifications

Design Patterns

Cache-aside pattern for toggle caching

Publish-subscribe for real-time toggle updates

Circuit breaker pattern to handle toggle service unavailability

Feature flag pattern for conditional code execution

Canary release and gradual rollout strategies

Reference Architecture

                +---------------------+
                |  Management Console |
                +----------+----------+
                           |
                           | REST API
                           v
                +---------------------+       +----------------+
                | Feature Toggle      |<----->| Audit Logging  |
                | Configuration       |       +----------------+
                | Service             |
                +----------+----------+
                           |
               +-----------+------------+
               |                        |
       +-------v-------+        +-------v-------+
       | Toggle Store  |        | Message Queue |
       | (Redis/Etcd)  |        | (Pub/Sub)     |
       +-------+-------+        +-------+-------+
               |                        |
               | Cache-aside            | Notifications
               |                        |
       +-------v-------+        +-------v-------+
       | Microservices |        | Microservices |
       | (Toggle SDK)  |        | (Toggle SDK)  |
       +---------------+        +---------------+

Components

Feature Toggle Configuration Service

Node.js/Java Spring Boot REST API

Central service to manage toggle states and provide toggle data to microservices

Toggle Store

Redis or Etcd

Fast key-value store to hold current toggle states for low latency access

Message Queue

Kafka or RabbitMQ

Publish-subscribe system to notify microservices of toggle updates in real-time

Management Console

React or Angular web app

User interface for product owners to create, update, and monitor feature toggles

Audit Logging System

Elasticsearch or relational DB

Store history of toggle changes for compliance and debugging

Toggle SDK

Lightweight client library in microservice language

Provide microservices with APIs to check toggle states efficiently and handle updates

Request Flow

1. 1. Product owner updates toggle state via Management Console.

2. 2. Console sends update request to Feature Toggle Configuration Service.

3. 3. Configuration Service validates and writes toggle state to Toggle Store.

4. 4. Configuration Service publishes toggle update event to Message Queue.

5. 5. Microservices subscribe to Message Queue and receive toggle update notifications.

6. 6. Microservices update local cache of toggles via Toggle SDK.

7. 7. On feature check, microservice queries local cache for toggle state to decide feature behavior.

8. 8. Audit Logging System records toggle changes asynchronously.

Database Schema

Entities: - FeatureToggle: id (PK), name, type (boolean, percentage, user-targeted), description, created_at, updated_at - ToggleState: toggle_id (FK), value (boolean or percentage), conditions (JSON for user targeting), updated_at - AuditLog: id (PK), toggle_id (FK), user_id, old_value, new_value, timestamp Relationships: - FeatureToggle 1:N ToggleState (history or environment-specific states) - FeatureToggle 1:N AuditLog

Scaling Discussion

Bottlenecks

Toggle Store read latency under heavy load

Message Queue throughput for high frequency toggle updates

Configuration Service CPU and memory under many concurrent requests

Microservice SDK cache synchronization delays

Audit Logging storage growth and query performance

Solutions

Use Redis cluster or Etcd cluster for horizontal scaling of toggle store

Partition Message Queue topics and use consumer groups for parallel processing

Deploy multiple instances of Configuration Service behind load balancer

Implement local cache with TTL and fallback to store for cache misses

Archive old audit logs and use efficient indexing for queries

Interview Tips

Time: Spend 10 minutes clarifying requirements and constraints, 20 minutes designing architecture and data flow, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing.