Loose coupling in Microservices - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to show a key benefit of loose coupling in microservices.

Microservices

Microservices communicate asynchronously using [1] to reduce dependencies.

Drag options to blanks, or click blank then click option'

Amessage queues

Bshared databases

Cdirect database calls

Dmonolithic calls

Attempts:

3 left

💡 Hint

Common Mistakes

Choosing shared databases causes tight coupling.

Direct database calls create dependencies.

Message queues enable asynchronous communication, which helps services remain independent and loosely coupled.

2fill in blank

medium

Complete the code to implement loose coupling by using {{BLANK_1}} for service discovery.

Microservices

Services register themselves with a [1] to enable dynamic lookup instead of hardcoded addresses.

Drag options to blanks, or click blank then click option'

Ashared file system

Bstatic IP list

Cservice registry

Ddirect URL

Attempts:

3 left

💡 Hint

Common Mistakes

Using static IPs leads to tight coupling.

Shared file systems are not typical for service discovery.

A service registry allows services to find each other dynamically, reducing tight dependencies on fixed addresses.

3fill in blank

hard

Complete the code to identify the communication style in {{BLANK_1}} causing tight coupling.

Microservices

Service A calls Service B directly via [1], causing tight coupling.

Drag options to blanks, or click blank then click option'

Amessage queues

Bsynchronous HTTP calls

Cevent-driven messaging

Dasynchronous events

Attempts:

3 left

💡 Hint

Common Mistakes

Choosing asynchronous methods here is correct for loose coupling, but the question asks to identify the tight coupling method.

Synchronous HTTP calls create tight coupling because Service A waits for Service B to respond directly.

4fill in blank

hard

Fill both blanks to implement loose coupling using {{BLANK_1}} and {{BLANK_2}}.

Microservices

Use [1] to decouple services and [2] to handle failures gracefully.

Drag options to blanks, or click blank then click option'

Amessage queues

Bcircuit breakers

Cdirect API calls

Dshared databases

Attempts:

3 left

💡 Hint

Common Mistakes

Using direct API calls increases coupling.

Shared databases create tight dependencies.

Message queues decouple services by asynchronous communication. Circuit breakers prevent cascading failures, improving resilience.

5fill in blank

hard

Fill all three blanks to design a loosely coupled microservice interaction: {{BLANK_1}} for communication, {{BLANK_2}} for service discovery, and {{BLANK_3}} for fault tolerance.

Microservices

Implement [1] to send messages, use [2] to find services dynamically, and apply [3] to prevent cascading failures.

Drag options to blanks, or click blank then click option'

Amessage queues

Bservice registry

Ccircuit breakers

Ddirect HTTP calls

Attempts:

3 left

💡 Hint

Common Mistakes

Choosing direct HTTP calls increases tight coupling.

Mixing up service registry and circuit breakers.

Message queues enable asynchronous communication, service registries allow dynamic discovery, and circuit breakers improve fault tolerance, all promoting loose coupling.

Practice

1. What does loose coupling mean in microservices architecture?

easy

A. Services depend on each other as little as possible

B. Services share the same database directly

C. Services are tightly connected with direct calls

D. Services must be deployed together always

Solution

1. Step 1: Understand the meaning of coupling

   Coupling means how much services rely on each other. Tight coupling means strong dependence.

2. Step 2: Identify loose coupling meaning

   Loose coupling means services depend on each other as little as possible to allow flexibility and easier changes.

3. Final Answer:

   Services depend on each other as little as possible -> Option A

4. Quick Check:

   Loose coupling = minimal service dependency [OK]

Hint: Loose coupling means minimal dependency between services [OK]

Common Mistakes:

• Confusing loose coupling with shared databases
• Thinking tight connections are loose coupling
• Assuming services must deploy together

2. Which of the following is a common way to achieve loose coupling between microservices?

easy

A. Calling services synchronously with blocking

B. Direct database sharing

C. Hardcoding service URLs in code

D. Using message queues or event buses

Solution

1. Step 1: Identify methods for service communication

   Direct database sharing and hardcoding URLs create tight coupling. Synchronous blocking calls also increase dependency.

2. Step 2: Recognize loose coupling techniques

   Message queues or event buses act as intermediaries, decoupling services and allowing asynchronous communication.

3. Final Answer:

   Using message queues or event buses -> Option D

4. Quick Check:

   Loose coupling uses intermediaries like queues [OK]

Hint: Use intermediaries like queues for loose coupling [OK]

Common Mistakes:

• Choosing direct database sharing
• Selecting synchronous blocking calls
• Hardcoding service addresses

3. Consider two microservices communicating via a message queue. If Service A sends 3 messages and Service B processes 2 messages, what happens to the remaining message?

medium

A. It stays in the queue until processed

B. It is lost immediately

C. It causes Service B to crash

D. It is processed twice

Solution

1. Step 1: Understand message queue behavior

   Message queues store messages until consumers process them. Messages are not lost or duplicated by default.

2. Step 2: Analyze the scenario

   Service A sent 3 messages, Service B processed 2, so 1 message remains in the queue waiting for processing.

3. Final Answer:

   It stays in the queue until processed -> Option A

4. Quick Check:

   Unprocessed messages remain in queue [OK]

Hint: Unprocessed messages stay in queue until consumed [OK]

Common Mistakes:

• Assuming messages are lost if not processed immediately
• Thinking messages cause crashes if unprocessed
• Believing messages are processed multiple times by default

4. A developer hardcoded the URL of Service B inside Service A's code for direct calls. What is the main problem with this approach regarding loose coupling?

medium

A. It improves loose coupling by direct communication

B. It makes services independent and scalable

C. It creates tight coupling and reduces flexibility

D. It automatically handles failures gracefully

Solution

1. Step 1: Understand hardcoding impact

   Hardcoding URLs creates a fixed dependency, making it hard to change or replace services.

2. Step 2: Relate to loose coupling principles

   Loose coupling requires minimal direct dependencies; hardcoding violates this by tightly binding services.

3. Final Answer:

   It creates tight coupling and reduces flexibility -> Option C

4. Quick Check:

   Hardcoding URLs = tight coupling [OK]

Hint: Hardcoding URLs causes tight coupling, avoid it [OK]

Common Mistakes:

• Thinking hardcoding improves loose coupling
• Assuming it makes services scalable
• Believing it handles failures automatically

5. You want to design a microservices system that can continue working even if one service fails temporarily. Which design choice best supports loose coupling and fault tolerance?

hard

A. Use synchronous HTTP calls with retries and timeouts

B. Use a message queue to decouple services and allow asynchronous processing

C. Share a single database among all services for consistency

D. Deploy all services on the same server to reduce latency

Solution

1. Step 1: Analyze fault tolerance needs

   To handle temporary failures, services should not block or fail immediately when others are down.

2. Step 2: Evaluate design choices for loose coupling

   Message queues decouple services and allow asynchronous processing, so one service can continue while another recovers.

3. Step 3: Exclude other options

   Synchronous calls block and may fail if the other service is down. Shared databases create tight coupling. Same server deployment risks single point of failure.

4. Final Answer:

   Use a message queue to decouple services and allow asynchronous processing -> Option B

5. Quick Check:

   Message queues enable loose coupling and fault tolerance [OK]

Hint: Message queues enable async, fault-tolerant loose coupling [OK]

Common Mistakes:

• Choosing synchronous calls that block on failure
• Sharing databases causing tight coupling
• Deploying all services on one server risking failure