Module
Module 4 of 6Lesson 3 of 3~17 min

Third-party services, composite availability, build or buy

Every third-party service added to a critical journey makes it more fragile, and that risk is a product call. You learn to estimate how much availability you lose when several vendors are chained together, plan a degraded mode, weigh vendor lock-in and argue a build-or-buy choice.

Take this lesson: your first course is freeSee the full syllabus

Lesson objective

By the end of this lesson, you will be able to calculate the availability of a journey that depends on several services, specify a degraded mode for each non-essential dependency, assess vendor lock-in and argue a build or buy decision based on total cost.

Topics covered

  • third-party dependencies
  • composite availability
  • graceful degradation
  • build vs buy
  • vendor lock-in

Where it fits

Data, load and dependencies

Where does the data live, what will give way first under load, and what happens when a vendor goes down?

Lessons in this module

  1. Where does the data live, and when is it up to date?
  2. Handling the load, finding the bottleneck, deciding on a cache
  3. Third-party services, composite availability, build or buy (this lesson)

What you will learn in the course

This lesson is part of the course Read and challenge a technical architecture

  • Read an architecture diagram (context and container levels of the C4 model) and spot its components, flows, boundaries and gray areas.
  • Turn vague expectations ("fast", "reliable", "scalable") into measurable non-functional requirements, written as quality attribute scenarios.
  • Compare monolith, modular monolith and microservices, then synchronous calls and asynchronous processing, based on the team, the load and the consequences for the user.
  • Assess data choices (source of truth, transactions, replicas, consistency), scaling and caching, and spot the bottleneck of a user journey.
  • Assess dependencies on third-party services (composite availability, degraded mode, vendor lock-in) and a build or buy decision.
  • Frame an architecture trade-off, record it in an ADR and treat technical debt as a product decision.
  • Run an architecture review of your product or of a proposal, with ten questions, a risk register and explicit trade-offs.

Related courses