Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • S system-design-primer
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 173
    • Issues 173
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 190
    • Merge requests 190
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Donne Martin
  • system-design-primer
  • Merge requests
  • !641

Propose reliability non-functional requirements in the initial readme

  • Review changes

  • Download
  • Email patches
  • Plain diff
Closed Administrator requested to merge github/fork/andrewhowdencom/patch-1 into master Feb 09, 2022
  • Overview 1
  • Commits 1
  • Pipelines 0
  • Changes 1

Created by: andrewhowdencom

This commit introduces reliability nonfunctional requirements that should be queried during the initial needs analysis for system design.

These factors readily influence the technological choices a colleague might make, from the open source services to the language choices. Capturing them early, and using them to constrain the design is useful.

The questions are:

== How available does the system need to be?

Designed to capture the desired success rate of the system. If the system is 99% available, for example, a relatively high reliability from the dependency (~98 - 99%) can also be expected, or even higher levels if strategies to overcome intermittent failure in this service are used (e.g. request hedging).

== How fast does the system need to process requests?

Used to determine whether or not the system can be architected in an eventually consistent way, or needs a shorter control loop (such as an RPC system backed by a transactional data store).

== How tolerant of lossy or incorrect data is the business process?

Used to determine what type of data store should be used; what transactional guarantees that data store should have or where the application can take shortcuts to make the writes to such a data store cheaper (such as accepting a request but batching the write).

Review the Contributing Guidelines

Before submitting a pull request, verify it meets all requirements in the Contributing Guidelines.

Translations

See the Contributing Guidelines. Verify you've:

  • Tagged the language maintainer
  • Prefixed the title with a language code
    • Example: "ja: Fix ..."
Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: github/fork/andrewhowdencom/patch-1