Aggregates and entities in Microservices - Scalability & System Analysis

Scalability Analysis - Aggregates and entities

Growth Table: Aggregates and Entities in Microservices

Users / Requests	What Changes?
100 users	Single instance per microservice; aggregates handle entity consistency locally; simple database transactions.
10,000 users	Multiple instances of microservices; aggregates partitioned by business domain; database connection pooling; caching introduced.
1,000,000 users	Microservices scaled horizontally with load balancers; aggregates sharded by entity ID ranges; eventual consistency patterns; asynchronous messaging between services.
100,000,000 users	Global distribution of microservices; aggregates split further; CQRS and event sourcing used; cross-region replication; advanced caching and CDN for read-heavy data.

First Bottleneck

The database managing aggregates becomes the first bottleneck. Aggregates enforce consistency boundaries, so heavy write/read loads on entities cause contention and slow transactions.

Scaling Solutions

• Horizontal Scaling: Add more microservice instances behind load balancers to distribute traffic.
• Sharding Aggregates: Partition aggregates by entity ID or business domain to reduce contention.
• Caching: Use in-memory caches for read-heavy entity data to reduce database load.
• Eventual Consistency: Use asynchronous messaging and event sourcing to decouple aggregates and improve scalability.
• Database Replication: Use read replicas to scale read queries.
• CQRS Pattern: Separate read and write models to optimize performance.

Back-of-Envelope Cost Analysis

• At 1M users, assuming 10 requests per user per minute = ~166,000 requests/sec.
• Each microservice instance handles ~3,000 concurrent connections; need ~60 instances.
• Database handles ~5,000 QPS; sharding needed to distribute load.
• Storage depends on entity size; for 1M entities at 1KB each = ~1GB; grows with history if event sourcing used.
• Network bandwidth must support request and event message traffic; estimate 1 Gbps or more.

Interview Tip

Start by explaining aggregates as consistency boundaries in microservices. Discuss how entities inside aggregates are managed. Then describe scaling challenges as user load grows. Finally, propose solutions like sharding, caching, and asynchronous communication, linking each to the bottleneck it solves.

Self Check

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

Answer: Introduce read replicas and caching to reduce load on the primary database. Also consider sharding aggregates to distribute write load.

Key Result

Aggregates enforce consistency but cause database bottlenecks as load grows; scaling requires partitioning aggregates, caching, and asynchronous patterns.

Practice

1. In microservices, what is the main role of an aggregate root entity?

easy

A. It acts as a database for all microservices.

B. It stores unrelated data from different services.

C. It handles user interface rendering.

D. It controls all changes within the aggregate to keep data consistent.

Solution

1. Step 1: Understand aggregate root responsibility

   The aggregate root is the main entity that manages all changes inside its aggregate to ensure consistency.

2. Step 2: Eliminate unrelated options

   Options A, B, and D describe roles unrelated to aggregate roots in microservices.

3. Final Answer:

   It controls all changes within the aggregate to keep data consistent. -> Option D

4. Quick Check:

   Aggregate root controls changes = C [OK]

Hint: Aggregate root manages changes inside its group [OK]

Common Mistakes:

• Confusing aggregate root with database or UI component
• Thinking aggregate root stores unrelated data
• Assuming aggregate root handles external service data

2. Which of the following correctly represents an aggregate in a microservice domain model?

easy

A. Order (root) -> OrderItems (entities) -> PaymentDetails (entity)

B. OrderItems (root) -> Order -> PaymentDetails

C. PaymentDetails (root) -> Order -> OrderItems

D. Order -> PaymentDetails -> OrderItems (all roots)

Solution

1. Step 1: Identify the aggregate root

   In an order system, the Order is the root entity controlling related entities like OrderItems and PaymentDetails.

2. Step 2: Check the hierarchy correctness

   Order (root) -> OrderItems (entities) -> PaymentDetails (entity) shows Order as root with related entities under it, which is correct. Other options misplace roots or treat all as roots.

3. Final Answer:

   Order (root) -> OrderItems (entities) -> PaymentDetails (entity) -> Option A

4. Quick Check:

   Root entity is Order controlling others = A [OK]

Hint: Root entity leads related entities in aggregate [OK]

Common Mistakes:

• Assigning wrong entity as root
• Treating all entities as roots
• Ignoring aggregate boundaries

3. Given the aggregate root Customer with entities Address and Order, which operation should only be performed through Customer?

medium

A. Deleting Order independently from Customer

B. Directly updating an Order without Customer involvement

C. Adding a new Address via the Customer aggregate root

D. Querying Order data directly from the database

Solution

1. Step 1: Understand aggregate root control

   The aggregate root Customer controls all changes to its entities like Address and Order to maintain consistency.

2. Step 2: Identify allowed operations

   Adding a new Address should go through Customer. Direct updates or deletes bypassing root break consistency.

3. Final Answer:

   Adding a new Address via the Customer aggregate root -> Option C

4. Quick Check:

   Changes go through root entity = A [OK]

Hint: All changes pass through aggregate root only [OK]

Common Mistakes:

• Updating entities directly without root
• Deleting entities independently
• Confusing querying with updating

4. You have a microservice with an aggregate root Invoice and entities LineItem. The code allows direct modification of LineItem without Invoice. What is the main problem?

medium

A. Performance will improve due to direct access.

B. Data consistency may break because changes bypass the aggregate root.

C. It will reduce network calls between services.

D. It simplifies the codebase without side effects.

Solution

1. Step 1: Identify aggregate root role in consistency

   The aggregate root Invoice ensures all changes to LineItem are consistent and valid.

2. Step 2: Analyze direct modification impact

   Directly modifying LineItem bypasses Invoice, risking inconsistent or invalid data.

3. Final Answer:

   Data consistency may break because changes bypass the aggregate root. -> Option B

4. Quick Check:

   Bypassing root risks consistency = B [OK]

Hint: Bypass root risks data consistency [OK]

Common Mistakes:

• Assuming direct access improves design
• Ignoring consistency importance
• Confusing performance with correctness

5. You design a microservice for a shopping cart system. The cart is an aggregate root with entities like CartItem and Discount. Which design choice best ensures data consistency and scalability?

hard

A. Make Cart the aggregate root controlling all CartItem and Discount changes.

B. Use a single database table for Cart, CartItem, and Discount without aggregates.

C. Store CartItem and Discount in separate microservices with no coordination.

D. Allow CartItem and Discount to be updated independently without Cart involvement.

Solution

1. Step 1: Apply aggregate root principle for consistency

   Cart as aggregate root should control all changes to CartItem and Discount to keep data consistent.

2. Step 2: Consider scalability and design best practices

   Centralizing changes through Cart allows easier management and scaling of the microservice without data conflicts.

3. Step 3: Evaluate other options

   Options A and C risk inconsistency; B ignores aggregate design and can cause complexity.

4. Final Answer:

   Make Cart the aggregate root controlling all CartItem and Discount changes. -> Option A

5. Quick Check:

   Aggregate root controls changes for consistency and scale = D [OK]

Hint: Aggregate root controls related entities for consistency and scale [OK]

Common Mistakes:

• Allowing independent updates breaking consistency
• Splitting tightly coupled entities into separate services
• Ignoring aggregate design principles