Art of Software Reuse
  • About
  • Introduction
  • Why Do Reuse Efforts Fail?
    • Common Pitfalls
    • Conway's Law
    • Care About Risks
    • Pursuing Perfection
    • Lack of Domain Focus
    • Entropy
  • Tenets
  • Success Factors
    • Revisit Assumptions
    • Communicate, Constantly
    • Collaborate
    • Review Code
    • Be Domain Driven
    • Target Quick Wins
    • Reduce Friction
    • Document
    • Build for Immediate Use
    • Address Support Needs
    • Managing Complexity
  • Practices
    • Minimise Jargon
    • Leverage Interception Points
    • Delay Commitment
    • Never Waste A Production Incident
    • Be Disciplined
    • Be Demand Driven
    • Continuous Alignment
    • Iterate, Iterate, Iterate
    • Build a Product Line
    • Understand Lack of Reuse
  • Design
    • Wrap Legacy APIs
    • Think Products, Not Applications
    • Identify Common Needs
    • Create Common Connectivity Components
    • Consistent APIs
    • Manage Domain Variations
    • Evolve Functionality Iteratively
    • Offer Reusable Assets with Multiple Interfaces
    • Leverage Services Across Functional Flows
    • Mediate Service Requests & Responses
    • Refactoring
    • Abstract Utility Functions
    • Reduce Technical Debt
    • Facilitate Extensibility
    • Encapsulate Variations Using Patterns
    • Understand Adoption Barriers
    • Ease Testability
    • Supportability
  • Tips
  • Resources
Powered by GitBook
On this page

Was this helpful?

  1. Design

Supportability

There is an expanded set of capabilities that are also necessary when addressing non-functional requirements – those that are very relevant specially when your reusable component or service grows in popularity and usage. They fall under two categories: operational agility and fault-tolerance. Here are a few candidate capabilities in both these categories:

Operational Agility / Supportability:

  • Ability to enable / disable both services and operations within a service

  • Ability to provision additional service instances based on demand (elastic scaling)

  • Maintenance APIs for managing resources (reset connection pool, individual connections, clear cached data, etc.)

  • Ability to view Service APIs that are breaching and ones that are the risk of breaching operational SLAs

  • Model and detect out of band behavior with respect to resource consumption, transaction volumes, usage trends during a time period etc.

Fault Tolerance:

  • Failing fast when there is no point executing operations partially

  • Ability to detect denial of service attacks from malicious clients

  • Ability to gracefully handle unexpected usage spikes via load shedding, re-balancing, deferring non-critical tasks, etc.

  • Detecting failures that impact individual operations as well as services as a whole

  • Dealing with unavailable downstream dependencies

  • Leveraging time outs when integrating with one or more dependencies

  • Automatically recovering from component failures

It is also important to point out that both these aspects are heavily interconnected and influence each other.

PreviousEase TestabilityNextTips

Last updated 5 years ago

Was this helpful?