Microservice Contracts — Vocabulary and Discussion Language
Learn vocabulary for discussing service contracts: interface versioning, breaking changes, and consumer-driven contracts.
0 / 30 completed
1 / 30
What is a 'service contract' in microservices vocabulary?
A service contract defines the public API interface: endpoints, HTTP methods, request schemas, response schemas, error codes, authentication requirements, and rate limits. The consuming service can only depend on what is in the contract — internal implementation can change freely. The owning service is responsible for maintaining the contract.
2 / 30
What is a 'breaking change' in API versioning vocabulary?
Breaking change: any API change that existing consumers must update their code to handle. Examples: removing a response field, changing a field type, renaming an endpoint, adding a required request parameter. Non-breaking: adding an optional field, adding a new endpoint, adding values to an enum (with caution). Semantic versioning (major version bump) signals breaking changes.
3 / 30
What is 'consumer-driven contract testing' (CDC) in microservices vocabulary?
Consumer-Driven Contracts (Pact, Spring Cloud Contract): each consumer publishes what it expects from the provider (specific request-response pairs). The provider runs all consumer contracts in its test suite to verify it satisfies every consumer. This prevents breaking changes without provider-consumer integration tests — catching breaking changes in CI before they reach production.
4 / 30
What is 'graceful degradation' in microservices communication vocabulary?
Graceful degradation: if Service A depends on Service B, and B is down, A should not fail completely. Instead: return cached data, return partial results with a warning, disable the affected feature, or fall back to defaults. Graceful degradation prevents cascade failures — where one service outage cascades through the system.
5 / 30
What is 'idempotency' in microservices and API vocabulary?
Idempotency: POST /orders called once vs. called 3 times (due to retries after network failure) should result in one order, not three. Idempotency is typically implemented with a client-supplied idempotency key: the first request with key X creates the order; subsequent requests with the same key X return the same response without creating duplicate orders.
6 / 30
Alex (Lead Developer) comments on a PR:
"This service now returns the user's full name instead of just their shortened identifier. This is a breaking change and needs to be documented clearly for consumers."
The use of 'breaking change' here refers to a change that impacts existing consumers of the API. While documenting is important, the core issue is about the impact on code using the service. Options A and D misunderstand the meaning of 'breaking change' in this context; option C highlights the potential for misuse of the term.
7 / 30
Sarah (DevOps Engineer) sends a Slack message to the team:
'We're seeing increased latency when calling the Payment Service from the Order Service. The logs indicate a retry loop is firing frequently. We need to investigate if we can implement a contract that guarantees response times under 200ms.'
This scenario focuses on proactively establishing a service contract. The Slack message correctly identifies the need to define a specific, quantifiable requirement (response time) as part of the agreement between the services. Option A is incorrect; latency issues require investigation, not accepting slow performance. Option D misinterprets retry loops.
8 / 30
Ben (API Developer) writes a PR description for a new version of the User Service API:
'Version 2.0 introduces support for nested profiles and allows users to specify their preferred language. The contract now includes a schema definition for these changes.'
This question tests understanding of contracts as a formal agreement. The PR description correctly highlights that updating the contract (specifically the schema) is necessary when introducing new features or changing existing data structures. Option A misunderstands backward compatibility; option D is a misleading statement about version requests.
9 / 30
Chloe (Developer) is discussing an issue with her team during a standup:
'If the Order Service fails to receive confirmation from the Payment Service after three attempts, we should gracefully degrade and return a 'payment failed' status to the user.'
'Graceful degradation' describes a strategy for handling failures. It acknowledges that services might not always be available and focuses on maintaining functionality rather than attempting to force a successful outcome. This approach is realistic regarding the complexities of microservice communication, while option A is an unrealistic guarantee.
10 / 30
David (Senior Developer) explains idempotency to a junior developer:
'Idempotency means that if you send the same payment request twice, it should have the same effect as sending it once. This is crucial for preventing accidental double charges.'
Idempotency focuses on the *effect* of repeating a request, not necessarily perfect data consistency. It's a core principle for designing resilient APIs and microservices. Option A is too broad; option D is factually incorrect – idempotency is a vital concept in distributed systems.
11 / 30
Alex (Lead Developer) comments on a PR:
"This service now returns the user's full name instead of just their shortened identifier. This is a breaking change and needs to be documented clearly for consumers."
The use of 'breaking change' here refers to a change that impacts existing consumers of the API. While documenting is important, the core issue is about the impact on code using the service. Options A and D misunderstand the meaning of 'breaking change' in this context; option C highlights the potential for misuse of the term.
12 / 30
Sarah (DevOps Engineer) sends a Slack message to the team:
'We're seeing increased latency when calling the Payment Service from the Order Service. The logs indicate a retry loop is firing frequently. We need to investigate if we can implement a contract that guarantees response times under 200ms.'
This scenario focuses on proactively establishing a service contract. The Slack message correctly identifies the need to define a specific, quantifiable requirement (response time) as part of the agreement between the services. Option A is incorrect; latency issues require investigation, not accepting slow performance. Option D misinterprets retry loops.
13 / 30
Ben (API Developer) writes a PR description for a new version of the User Service API:
'Version 2.0 introduces support for nested profiles and allows users to specify their preferred language. The contract now includes a schema definition for these changes.'
This question tests understanding of contracts as a formal agreement. The PR description correctly highlights that updating the contract (specifically the schema) is necessary when introducing new features or changing existing data structures. Option A misunderstands backward compatibility; option D is a misleading statement about version requests.
14 / 30
Chloe (Developer) is discussing an issue with her team during a standup:
'If the Order Service fails to receive confirmation from the Payment Service after three attempts, we should gracefully degrade and return a 'payment failed' status to the user.'
'Graceful degradation' describes a strategy for handling failures. It acknowledges that services might not always be available and focuses on maintaining functionality rather than attempting to force a successful outcome. This approach is realistic regarding the complexities of microservice communication, while option A is an unrealistic guarantee.
15 / 30
David (Senior Developer) explains idempotency to a junior developer:
'Idempotency means that if you send the same payment request twice, it should have the same effect as sending it once. This is crucial for preventing accidental double charges.'
Idempotency focuses on the *effect* of repeating a request, not necessarily perfect data consistency. It's a core principle for designing resilient APIs and microservices. Option A is too broad; option D is factually incorrect – idempotency is a vital concept in distributed systems.
16 / 30
Alex (Lead Developer) comments on a PR:
"This service now returns the user's full name instead of just their shortened identifier. This is a breaking change and needs to be documented clearly for consumers."
The use of 'breaking change' here refers to a change that impacts existing consumers of the API. While documenting is important, the core issue is about the impact on code using the service. Options A and D misunderstand the meaning of 'breaking change' in this context; option C highlights the potential for misuse of the term.
17 / 30
Sarah (DevOps Engineer) sends a Slack message to the team:
'We're seeing increased latency when calling the Payment Service from the Order Service. The logs indicate a retry loop is firing frequently. We need to investigate if we can implement a contract that guarantees response times under 200ms.'
This scenario focuses on proactively establishing a service contract. The Slack message correctly identifies the need to define a specific, quantifiable requirement (response time) as part of the agreement between the services. Option A is incorrect; latency issues require investigation, not accepting slow performance. Option D misinterprets retry loops.
18 / 30
Ben (API Developer) writes a PR description for a new version of the User Service API:
'Version 2.0 introduces support for nested profiles and allows users to specify their preferred language. The contract now includes a schema definition for these changes.'
This question tests understanding of contracts as a formal agreement. The PR description correctly highlights that updating the contract (specifically the schema) is necessary when introducing new features or changing existing data structures. Option A misunderstands backward compatibility; option D is a misleading statement about version requests.
19 / 30
Chloe (Developer) is discussing an issue with her team during a standup:
'If the Order Service fails to receive confirmation from the Payment Service after three attempts, we should gracefully degrade and return a 'payment failed' status to the user.'
'Graceful degradation' describes a strategy for handling failures. It acknowledges that services might not always be available and focuses on maintaining functionality rather than attempting to force a successful outcome. This approach is realistic regarding the complexities of microservice communication, while option A is an unrealistic guarantee.
20 / 30
David (Senior Developer) explains idempotency to a junior developer:
'Idempotency means that if you send the same payment request twice, it should have the same effect as sending it once. This is crucial for preventing accidental double charges.'
Idempotency focuses on the *effect* of repeating a request, not necessarily perfect data consistency. It's a core principle for designing resilient APIs and microservices. Option A is too broad; option D is factually incorrect – idempotency is a vital concept in distributed systems.
21 / 30
Alex (Lead Developer) comments on a PR:
"This service now returns the user's full name instead of just their shortened identifier. This is a breaking change and needs to be documented clearly for consumers."
The use of 'breaking change' here refers to a change that impacts existing consumers of the API. While documenting is important, the core issue is about the impact on code using the service. Options A and D misunderstand the meaning of 'breaking change' in this context; option C highlights the potential for misuse of the term.
22 / 30
Sarah (DevOps Engineer) sends a Slack message to the team:
'We're seeing increased latency when calling the Payment Service from the Order Service. The logs indicate a retry loop is firing frequently. We need to investigate if we can implement a contract that guarantees response times under 200ms.'
This scenario focuses on proactively establishing a service contract. The Slack message correctly identifies the need to define a specific, quantifiable requirement (response time) as part of the agreement between the services. Option A is incorrect; latency issues require investigation, not accepting slow performance. Option D misinterprets retry loops.
23 / 30
Ben (API Developer) writes a PR description for a new version of the User Service API:
'Version 2.0 introduces support for nested profiles and allows users to specify their preferred language. The contract now includes a schema definition for these changes.'
This question tests understanding of contracts as a formal agreement. The PR description correctly highlights that updating the contract (specifically the schema) is necessary when introducing new features or changing existing data structures. Option A misunderstands backward compatibility; option D is a misleading statement about version requests.
24 / 30
Chloe (Developer) is discussing an issue with her team during a standup:
'If the Order Service fails to receive confirmation from the Payment Service after three attempts, we should gracefully degrade and return a 'payment failed' status to the user.'
'Graceful degradation' describes a strategy for handling failures. It acknowledges that services might not always be available and focuses on maintaining functionality rather than attempting to force a successful outcome. This approach is realistic regarding the complexities of microservice communication, while option A is an unrealistic guarantee.
25 / 30
David (Senior Developer) explains idempotency to a junior developer:
'Idempotency means that if you send the same payment request twice, it should have the same effect as sending it once. This is crucial for preventing accidental double charges.'
Idempotency focuses on the *effect* of repeating a request, not necessarily perfect data consistency. It's a core principle for designing resilient APIs and microservices. Option A is too broad; option D is factually incorrect – idempotency is a vital concept in distributed systems.
26 / 30
Alex (Lead Developer) comments on a PR:
"This service now returns the user's full name instead of just their shortened identifier. This is a breaking change and needs to be documented clearly for consumers."
The use of 'breaking change' here refers to a change that impacts existing consumers of the API. While documenting is important, the core issue is about the impact on code using the service. Options A and D misunderstand the meaning of 'breaking change' in this context; option C highlights the potential for misuse of the term.
27 / 30
Sarah (DevOps Engineer) sends a Slack message to the team:
'We're seeing increased latency when calling the Payment Service from the Order Service. The logs indicate a retry loop is firing frequently. We need to investigate if we can implement a contract that guarantees response times under 200ms.'
This scenario focuses on proactively establishing a service contract. The Slack message correctly identifies the need to define a specific, quantifiable requirement (response time) as part of the agreement between the services. Option A is incorrect; latency issues require investigation, not accepting slow performance. Option D misinterprets retry loops.
28 / 30
Ben (API Developer) writes a PR description for a new version of the User Service API:
'Version 2.0 introduces support for nested profiles and allows users to specify their preferred language. The contract now includes a schema definition for these changes.'
This question tests understanding of contracts as a formal agreement. The PR description correctly highlights that updating the contract (specifically the schema) is necessary when introducing new features or changing existing data structures. Option A misunderstands backward compatibility; option D is a misleading statement about version requests.
29 / 30
Chloe (Developer) is discussing an issue with her team during a standup:
'If the Order Service fails to receive confirmation from the Payment Service after three attempts, we should gracefully degrade and return a 'payment failed' status to the user.'
'Graceful degradation' describes a strategy for handling failures. It acknowledges that services might not always be available and focuses on maintaining functionality rather than attempting to force a successful outcome. This approach is realistic regarding the complexities of microservice communication, while option A is an unrealistic guarantee.
30 / 30
David (Senior Developer) explains idempotency to a junior developer:
'Idempotency means that if you send the same payment request twice, it should have the same effect as sending it once. This is crucial for preventing accidental double charges.'
Idempotency focuses on the *effect* of repeating a request, not necessarily perfect data consistency. It's a core principle for designing resilient APIs and microservices. Option A is too broad; option D is factually incorrect – idempotency is a vital concept in distributed systems.
What will I practise in "Microservice Contracts — Vocabulary and Discussion Language"?
This module focuses on Microservices Language — real workplace phrasing you'll use on the job. It contains 30 scenario-based multiple-choice questions with instant feedback.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account or sign-up required.
How many questions does this exercise have?
This module includes 30 questions. Each one gives an immediate right/wrong result plus a full explanation of the correct phrasing.
What happens if I answer a question incorrectly?
You'll see the correct answer highlighted straight away, along with a plain-English explanation of why it's right and why the other options don't fit — mistakes are part of the learning here.
Can I retry the exercise if I want a better score?
Yes — use the 'Try again' button on the results screen to reset your score and go through the questions again. There's no limit on attempts.
Who is this Microservices Language exercise for?
It's aimed at IT professionals with working English who want to sound more natural and precise around microservices language — useful whether you're preparing for real conversations at work or just building confidence with the vocabulary.
Do I need an account to track my progress?
No account is needed. Your progress through the exercise is tracked locally in your browser for the current session, and you can replay the module at any time.
How is this different from reading a blog article?
This exercise is an interactive drill that tests and reinforces specific phrasing through multiple-choice questions with instant feedback, while blog articles explain concepts and vocabulary in prose. The two work well together.
Where can I find more Microservices Language exercises?
See the Microservices Language hub for more modules like this one, or browse the full Exercises page for other IT-English topics.
Can I complete this exercise on my phone?
Yes — every exercise on CoderSlingo is fully responsive and works on phones and tablets, so you can practise anywhere.