Domain-Driven Design (DDD) basics in Microservices - Scalability & System Analysis

Scalability Analysis - Domain-Driven Design (DDD) basics

Growth Table: Scaling Domain-Driven Design (DDD) in Microservices

Users	Data Volume	Service Count	Complexity	Communication
100 users	Small (MBs)	Few (1-3)	Low - simple domains	Direct calls, simple APIs
10,000 users	Medium (GBs)	Several (5-10)	Moderate - multiple bounded contexts	REST/gRPC with retries
1,000,000 users	Large (TBs)	Many (20+)	High - complex domain models	Event-driven, async messaging
100,000,000 users	Very Large (PBs)	Hundreds	Very High - multiple teams/domains	Advanced messaging, CQRS, eventual consistency

First Bottleneck

At small scale, the database becomes the first bottleneck because all domain data is stored centrally, causing contention and slow queries.

As users and services grow, the complexity of inter-service communication and data consistency across bounded contexts becomes the bottleneck.

At very large scale, network latency and message broker throughput limit system responsiveness.

Scaling Solutions

• Database Scaling: Use database per bounded context to isolate data and reduce contention.
• Service Decomposition: Split monolith into microservices aligned with bounded contexts.
• Asynchronous Communication: Use event-driven messaging (Kafka, RabbitMQ) to decouple services.
• CQRS and Event Sourcing: Separate read/write models to optimize performance and scalability.
• API Gateways and Load Balancers: Manage traffic and provide single entry points.
• Cache Frequently Used Data: Use Redis or similar to reduce database load.
• Partitioning and Sharding: Distribute data across multiple databases by domain or customer.

Back-of-Envelope Cost Analysis

Assuming 1 million users with 10 requests per second each:

• Total requests: 10 million requests per second (distributed across services)
• Database QPS per instance: 5,000 -> Need ~2,000 DB instances or sharding
• Message broker throughput: Kafka can handle ~1 million messages/sec per cluster -> multiple clusters needed
• Storage: TBs to PBs depending on domain data retention
• Network bandwidth: 1 Gbps per server -> horizontal scaling with load balancers

Interview Tip

Start by explaining the concept of bounded contexts and how DDD helps manage complexity by aligning microservices with business domains.

Discuss how scaling affects data consistency and communication patterns.

Outline bottlenecks and propose concrete solutions like database per context, event-driven architecture, and CQRS.

Use real-life analogies like teams working on different parts of a product to explain bounded contexts.

Self Check

Your database handles 1000 QPS. Traffic grows 10x. What do you do first?

Answer: Introduce read replicas and caching to reduce load, then consider splitting the database by bounded contexts to scale horizontally.

Key Result

DDD scales by decomposing complex domains into bounded contexts, each with its own data and services, enabling independent scaling and reducing bottlenecks in databases and communication.

Practice

1. What is the main purpose of Domain-Driven Design (DDD) in microservices?

easy

A. To align software design closely with business needs

B. To improve database query performance

C. To create user interfaces faster

D. To reduce network latency between services

Solution

1. Step 1: Understand the goal of DDD

   DDD focuses on modeling software based on the real business domain and its rules.

2. Step 2: Compare options with DDD goals

   Only aligning software with business needs matches DDD's main purpose.

3. Final Answer:

   To align software design closely with business needs -> Option A

4. Quick Check:

   DDD = Align software with business [OK]

Hint: DDD = software matches business needs [OK]

Common Mistakes:

• Confusing DDD with performance optimization
• Thinking DDD is about UI or network improvements
• Assuming DDD is only about coding style

2. Which of the following is a correct way to describe a 'Bounded Context' in DDD?

easy

A. A network protocol used for service communication

B. A database table shared by all microservices

C. A UI component that handles user input

D. A clear boundary within which a domain model applies

Solution

1. Step 1: Define Bounded Context

   It is a boundary that defines where a particular domain model is valid and consistent.

2. Step 2: Match options to definition

   Only 'a clear boundary within which a domain model applies' correctly describes a Bounded Context.

3. Final Answer:

   A clear boundary within which a domain model applies -> Option D

4. Quick Check:

   Bounded Context = domain model boundary [OK]

Hint: Bounded Context = domain model boundary [OK]

Common Mistakes:

• Thinking it is a shared database table
• Confusing it with UI or network concepts
• Assuming it is a technical infrastructure term

3. Given the following description, which DDD building block is being described?
A unique object with an identity that persists over time and changes state.

medium

A. Value Object

B. Entity

C. Aggregate

D. Repository

Solution

1. Step 1: Understand the description

   The object has a unique identity and can change state over time.

2. Step 2: Match description to DDD concepts

   Entities have unique identities and mutable state; value objects do not have identity.

3. Final Answer:

   Entity -> Option B

4. Quick Check:

   Unique identity + state = Entity [OK]

Hint: Entity = unique identity and state [OK]

Common Mistakes:

• Confusing Entity with Value Object
• Thinking Aggregate is a single object only
• Mixing Repository with domain objects

4. You have a microservice with a large domain model mixing unrelated concepts. What DDD principle helps fix this?

medium

A. Define clear Bounded Contexts to separate domains

B. Avoid using entities and only use value objects

C. Merge all services into one monolith

D. Use a single aggregate for all entities

Solution

1. Step 1: Identify the problem

   The domain model is large and mixes unrelated concepts, causing complexity.

2. Step 2: Apply DDD principle

   Bounded Contexts separate different domain areas to keep models clear and manageable.

3. Final Answer:

   Define clear Bounded Contexts to separate domains -> Option A

4. Quick Check:

   Separate domains with Bounded Contexts [OK]

Hint: Separate domains using Bounded Contexts [OK]

Common Mistakes:

• Trying to use one aggregate for everything
• Merging services instead of separating
• Removing entities incorrectly

5. In a microservices system using DDD, which approach best ensures data consistency within a complex domain involving multiple aggregates?

hard

A. Use transactions spanning multiple microservices

B. Store all data in a single shared database

C. Design aggregates as consistency boundaries and use eventual consistency between them

D. Avoid aggregates and use only value objects for all data

Solution

1. Step 1: Understand consistency in DDD aggregates

   Aggregates define consistency boundaries; transactions should not span multiple aggregates or services.

2. Step 2: Choose best practice for microservices

   Use eventual consistency and asynchronous communication between aggregates to maintain scalability and reliability.

3. Final Answer:

   Design aggregates as consistency boundaries and use eventual consistency between them -> Option C

4. Quick Check:

   Aggregates = consistency boundaries + eventual consistency [OK]

Hint: Aggregates limit transactions; use eventual consistency [OK]

Common Mistakes:

• Trying distributed transactions across services
• Using a shared database breaking microservice boundaries
• Ignoring aggregates and consistency rules