Microservice Flashcards
Question:
What are the key principles to consider when defining microservice boundaries?
Answer:
1. Information Hiding:
- Hide internal implementation details and expose only necessary interfaces to ensure changes within a service do not affect others.
-
Cohesion:
- Ensure high cohesion by focusing each service on a single business capability or domain.
-
Coupling:
- Maintain low coupling by minimizing dependencies between services to allow for independent evolution.
-
Domain-Driven Design (DDD):
- Align microservice boundaries with business domains using concepts like bounded contexts and
Question:
Can you explain the concept of information hiding in the context of microservices?
.
Ready for the next question?
Answer:
Information Hiding: In microservices, information hiding means each service encapsulates its internal details and exposes only the necessary interfaces for interaction, promoting loose coupling and independent deployability.
Example - Order Service in a Bookstore:
Public API:
- createOrder
- updateOrder
- deleteOrder
- getListOfPreviousOrders
Internal Processes Hidden:
- Internal order creation, updating, and deletion processes.
- Order data management (e.g., soft delete, data storage details).
- Handling other users’ orders and internal data persistence logic.
Benefits:
1. Loose Coupling: Independent changes without affecting other services.
2. Security: Protects sensitive information and processes.
3. Simplified Interfaces: Easier to understand and use the service.
4. Flexibility: Allows internal implementation changes without API changes
What are the types of coupling that can occur between microservices, and how can they be managed?
.
1. Domain Coupling:
- Example: Order Service and Inventory Service both need to understand the “order” concept. Changes in the “order” definition require updates in both services.
- Problem: Coordinated updates across services, hindering independent deployment.
2. Pass-Through Coupling:
- Example: Payment Service passes order requests to Shipping Service without processing them.
- Problem: Dependency chain and single point of failure. Changes in order request format affect all services in the chain.
3. Common Coupling:
- Example: Multiple services (User, Order, Payment) access a shared configuration file for database connection strings and service endpoints.
- Problem: Changes to shared configuration can cause widespread issues and make debugging difficult.
4. Content Coupling:
- Example: Inventory Service directly accesses Order Service’s database to retrieve order details.
- Problem: Direct database access creates strong dependencies. Schema changes in Order Service can break Inventory Service
Question:
Can not using domain events contribute to creating a “big ball of mud” architecture in microservices? If so, how?
Answer:
Yes, not using domain events can contribute to creating a “big ball of mud” architecture. Here’s how:
Problems Without Domain Events:
Direct Synchronous Calls:
Leads to tight coupling between services.
Changes in one service can break others.
Reduces system resilience to failures.
Shared Databases:
Results in a tightly coupled, monolithic data model.
Schema changes affect multiple services.
Difficult to manage and evolve the database.
Inconsistent State:
Hard to maintain consistent state across services.
Each service may have a partial view of the data.
Leads to outdated or incorrect data.
Benefits of Using Domain Events:
Asynchronous Communication:
Decouples services by allowing independent reactions to events.
Services emit and listen for events without direct calls.
Event-Driven Architecture:
Uses event brokers to handle publishing and subscribing of events.
Further decouples services and ensures loose coupling.
Resilience and Scalability:
Enables asynchronous processing, improving resilience.
Allows services to scale independently.
Consistent State Management:
Keeps state consistent across services.
Ensures all services have a real-time, consistent view of data.
How does domain-driven design (DDD) help in modeling microservices?
Answer:
1. Understanding the Domain:
Approach: Deep understanding of the business domain.
Benefit: Ensures each microservice corresponds to a specific area of business functionality.
2. Ubiquitous Language:
Approach: Common language shared by developers and domain experts.
Benefit: Reduces miscommunication and errors, ensuring consistent understanding.
3. Bounded Contexts:
Approach: Defines boundaries within which a particular model is applicable.
Benefit: Ensures each service has a well-defined scope, reducing ambiguity and overlap.
4. Aggregates:
Approach: Clusters of domain objects treated as a single unit.
Benefit: Maintains data consistency within a microservice, promoting encapsulation.
5. Domain Events:
Approach: Captures significant occurrences within the domain.
Benefit: Enables decoupled communication between services, supporting asynchronous interactions.
6. Strategic Design:
Approach: Distinguishes between core, supporting, and generic subdomains.
Benefit: Prioritizes efforts on core domains, ensuring microservices deliver the most business value.
Example:
Core Domain: Identify key areas like order processing, payment handling.
Ubiquitous Language: Use consistent terms like “Order,” “Payment,” “Inventory.”
Bounded Contexts: Define contexts like Order Management, Payment Processing.
Aggregates: Model aggregates like an Order with Order Items.
Domain Events: Use events like OrderPlaced, PaymentProcessed.
What is a key principle to consider when defining microservice boundaries?
a) Information hiding
b) Code sharing
c) Centralized databases
d) Monolithic structure
Question 1:
What is a key principle to consider when defining microservice boundaries?
a) Information hiding
b) Code sharing
c) Centralized databases
d) Monolithic structure
Which of the following scenarios demonstrates poor use of bounded contexts in microservices?
a) The Order Service handles all order-related data and processes, while the Inventory Service manages stock levels independently.
b) The Payment Service manages payment transactions, but also directly accesses and modifies customer details stored in the Customer Service.
c) The Shipping Service processes shipping requests and communicates with the Order Service through well-defined APIs.
d) The Recommendation Service uses data from the Order Service and Inventory Service but only through their public APIs.
Answer: b) The Payment Service manages payment transactions, but also directly accesses and modifies customer details stored in the Customer Service.
Which type of coupling occurs when multiple services share global data or configurations?
a) Domain coupling
b) Pass-through coupling
c) Common coupling
d) Content coupling
Answer: c) Common coupling
How does Domain-Driven Design (DDD) help in modeling microservices?
a) By using a monolithic approach
b) By aligning microservices with business domains
c) By ensuring all services use the same database
d) By ignoring business processes
Answer: b) By aligning microservices with business domains
What is a bounded context in DDD?
a) A centralized database
b) A boundary within which a particular model is defined and applicable
c) A type of coupling
d) An external API
Answer: b) A boundary within which a particular model is defined and applicable
Which technique involves identifying domain events, commands, and aggregates to model microservices?
a) Code refactoring
b) Event storming
c) Database normalization
d) Load testing
Answer: b) Event storming
Which criterion is NOT typically used to define microservice boundaries?
a) Volatility
b) Scalability
c) Data ownership
d) Single-threaded execution
Answer: d) Single-threaded execution
Question 8:
How does using domain events benefit microservices?
a) By increasing coupling between services
b) By decoupling services and supporting asynchronous communication
c) By centralizing all data processing
d) By making services more dependent on each other
Answer: b) By decoupling services and supporting asynchronous communication
What is the main benefit of defining microservice boundaries based on team structure and responsibilities?
a) Clear ownership and accountability
b) Increased system complexity
c) Shared data models
d) Uniform technology stack
Answer: a) Clear ownership and accountability
Which of the following is an alternative criterion to business domain boundaries when defining microservice boundaries?
a) Performance and latency
b) Centralized logging
c) Single point of failure
d) Direct database access
Answer: a) Performance and latency
