Contract testing (Pact) in Microservices - System Design Exercise

Design: Contract Testing System using Pact

Design the contract testing system architecture using Pact for microservices communication validation. Out of scope: detailed implementation of microservices themselves, network infrastructure.

Functional Requirements

FR1: Ensure that microservices can communicate correctly by verifying API contracts.

FR2: Allow consumer services to define expectations for provider services.

FR3: Enable provider services to verify they meet consumer expectations before deployment.

FR4: Support automated contract verification in CI/CD pipelines.

FR5: Provide clear reports on contract test results for developers.

FR6: Handle multiple versions of contracts for backward compatibility.

Non-Functional Requirements

NFR1: Support up to 100 microservices communicating asynchronously and synchronously.

NFR2: Contract verification latency should be under 1 minute in CI/CD pipelines.

NFR3: System availability target of 99.9% for contract repository and verification services.

NFR4: Contracts must be stored securely and versioned.

NFR5: Testing should not block production deployments unless contract violations occur.

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

Contract Repository (storage and versioning)

Consumer Test Suite (generates contracts)

Provider Verification Service

CI/CD Pipeline Integration

Notification and Reporting System

API Gateway or Service Mesh (optional for runtime contract enforcement)

Design Patterns

Consumer-Driven Contract Testing

Publish-Subscribe for contract updates

Versioning and Compatibility Management

Continuous Integration and Continuous Deployment

Fail-fast deployment on contract violation

Reference Architecture

  +-------------------+       +---------------------+       +---------------------+
  |                   |       |                     |       |                     |
  | Consumer Service 1|       | Consumer Service N  |       | Provider Service(s) |
  |  (Generates Pact) |       |  (Generates Pact)   |       |  (Verifies Pact)    |
  +---------+---------+       +----------+----------+       +----------+----------+
            |                            |                             |
            |                            |                             |
            |                            |                             |
            |                            |                             |
            v                            v                             v
  +----------------------------------------------------------------------------------+
  |                          Contract Repository (Pact Broker)                      |
  |  - Stores contracts securely and versioned                                     |
  |  - Allows providers to fetch contracts for verification                         |
  +----------------------------------------------------------------------------------+
                                         |
                                         |
                                         v
                          +-------------------------------+
                          | CI/CD Pipeline Integration     |
                          | - Runs consumer tests to publish|
                          |   contracts                     |
                          | - Runs provider verification    |
                          |   against contracts             |
                          +-------------------------------+
                                         |
                                         v
                          +-------------------------------+
                          | Notification & Reporting System |
                          | - Alerts on contract violations |
                          | - Provides test reports          |
                          +-------------------------------+

Components

Consumer Service

Any microservice framework

Generates Pact contracts describing expected interactions with provider services.

Provider Service

Any microservice framework

Verifies that the provider meets the contract expectations defined by consumers.

Contract Repository (Pact Broker)

Pact Broker (open-source or managed)

Stores, versions, and shares contracts between consumers and providers.

CI/CD Pipeline

Jenkins, GitHub Actions, GitLab CI, or similar

Automates running consumer tests to publish contracts and provider verification tests.

Notification & Reporting System

Email, Slack, or monitoring tools integration

Sends alerts and reports on contract test results to developers and teams.

Request Flow

1. 1. Consumer service runs tests that generate Pact contracts describing expected API interactions.

2. 2. Generated contracts are published to the Contract Repository (Pact Broker) with versioning metadata.

3. 3. Provider service fetches the latest relevant contracts from the Contract Repository.

4. 4. Provider runs verification tests against its API to ensure it meets consumer expectations.

5. 5. Verification results are sent back to the CI/CD pipeline.

6. 6. If verification passes, deployment proceeds; if it fails, alerts are sent via Notification System.

7. 7. Developers review reports and fix contract violations before redeploying.

Database Schema

Entities: - Contract: id, consumer_name, provider_name, version, content (JSON), created_at - VerificationResult: id, contract_id, provider_version, status (pass/fail), run_at, logs - Service: id, name, type (consumer/provider), created_at Relationships: - Contract links one Consumer Service to one Provider Service - VerificationResult links to one Contract and one Provider Service version

Scaling Discussion

Bottlenecks

Contract Repository performance under many concurrent reads/writes.

CI/CD pipeline delays due to large number of contract verifications.

Managing contract version explosion with many microservices and versions.

Notification overload from frequent contract failures.

Ensuring contract verification does not block critical deployments.

Solutions

Use scalable storage backend for Pact Broker with caching and CDN for contract retrieval.

Parallelize contract verification jobs in CI/CD pipelines and use incremental verification.

Implement contract version pruning and compatibility rules to reduce versions tested.

Aggregate notifications and use thresholds to reduce alert noise.

Set deployment policies to allow non-blocking warnings for minor contract changes and block only critical failures.

Interview Tips

Time: Spend 10 minutes understanding requirements and clarifying scope, 20 minutes designing architecture and data flow, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing.

Explain consumer-driven contract testing concept clearly.

Describe how Pact Broker manages contract sharing and versioning.

Show understanding of CI/CD integration for automated verification.

Discuss handling backward compatibility and version management.

Highlight importance of fast feedback and developer notifications.

Address scaling challenges realistically with practical solutions.

Practice

1. What is the main purpose of contract testing in microservices using Pact?

easy

A. To check database schema consistency

B. To test the user interface of a microservice

C. To verify that services agree on request and response formats

D. To measure the performance of a microservice

Solution

1. Step 1: Understand contract testing role

   Contract testing ensures that two services agree on how they communicate, specifically the request and response formats.

2. Step 2: Identify Pact's function

   Pact automates contract testing by creating and verifying these agreements between microservices.

3. Final Answer:

   To verify that services agree on request and response formats -> Option C

4. Quick Check:

   Contract testing = Verify service agreements [OK]

Hint: Contract testing checks communication agreements, not UI or performance [OK]

Common Mistakes:

• Confusing contract testing with UI testing
• Thinking contract testing checks database schemas
• Assuming contract testing measures performance

2. Which of the following is the correct Pact file format used to define a contract?

easy

A. JSON

B. YAML

C. XML

D. CSV

Solution

1. Step 1: Identify Pact contract format

   Pact contracts are written in JSON format to describe interactions between services.

2. Step 2: Eliminate other formats

   YAML, XML, and CSV are not used by Pact for contract files.

3. Final Answer:

   JSON -> Option A

4. Quick Check:

   Pact contract format = JSON [OK]

Hint: Pact contracts are JSON files describing service interactions [OK]

Common Mistakes:

• Assuming Pact uses YAML or XML
• Confusing data formats with contract formats
• Thinking CSV can describe complex contracts

3. Given the following Pact interaction snippet, what is the expected response status code?

{"request": {"method": "GET", "path": "/users/123"}, "response": {"status": 200, "body": {"id": 123, "name": "Alice"}}}

medium

A. 404

B. 200

C. 500

D. 302

Solution

1. Step 1: Read the response status in the Pact snippet

   The response object shows "status": 200, indicating a successful request.

2. Step 2: Confirm status meaning

   Status 200 means OK, so the expected response code is 200.

3. Final Answer:

   200 -> Option B

4. Quick Check:

   Response status in Pact = 200 [OK]

Hint: Look for "status" field in response to find expected code [OK]

Common Mistakes:

• Confusing request method with response status
• Ignoring the status field in the response
• Choosing common error codes instead of actual status

4. A Pact test fails because the provider service returns an extra field not defined in the contract. What is the best way to fix this?

medium

A. Remove the extra field from the provider service response

B. Ignore the extra field in the provider service

C. Disable contract testing for this interaction

D. Update the contract to include the extra field

Solution

1. Step 1: Understand contract strictness

   Pact expects the provider response to match the contract exactly, including fields.

2. Step 2: Adjust contract or provider

   If the provider adds a new field, the contract must be updated to reflect this change to keep tests valid.

3. Final Answer:

   Update the contract to include the extra field -> Option D

4. Quick Check:

   Provider adds field -> update contract [OK]

Hint: Keep contract and provider response in sync to pass tests [OK]

Common Mistakes:

• Ignoring extra fields without updating contract
• Removing fields from provider causing data loss
• Disabling tests instead of fixing contract

5. You want to implement contract testing with Pact in a microservices system where multiple teams develop services independently. Which approach best ensures smooth integration?

hard

A. Each team publishes their Pact contracts to a shared broker for others to verify

B. Teams test contracts only locally without sharing

C. Use end-to-end tests only, skipping contract tests

D. Manually review API changes without automated tests

Solution

1. Step 1: Identify best practice for contract sharing

   Using a shared Pact broker allows teams to publish and verify contracts centrally, enabling independent development with integration confidence.

2. Step 2: Compare alternatives

   Local-only tests lack visibility; end-to-end tests are slower and less focused; manual reviews are error-prone.

3. Final Answer:

   Each team publishes their Pact contracts to a shared broker for others to verify -> Option A

4. Quick Check:

   Shared Pact broker = smooth integration [OK]

Hint: Use shared Pact broker for contract visibility and verification [OK]

Common Mistakes:

• Skipping contract tests for only end-to-end tests
• Not sharing contracts causing integration surprises
• Relying on manual API reviews