Design for uptime (Rough draft)

What design for uptime is not

is not about telling people which programming language to use
is not about telling people how to solve a problem
is not about telling people which set of technologies to use
is not one sided.
- Both parties (Provider and Consumer) commit to provide X experience and consume it in Z way/form

is a methodology for developing/maintaining products/services
is about defining what a customer/consumer can expect from a service/app/daemon like:
- Uptime
- Time to response/reply
- Data structure
is about defining how a customer/consumer should use a service/app/daemon
- B amount of requests per second/hour/day (Only if necessary)
- C Data is available at https://service.domain.tld/path/that/makes/sense/data/would/be/at
is about setting a basic/base communication layer

As an example, HTTP as the basic/base communication layer between our different services
- HTTP Methods
  - GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE
- Remember we can use HTTP 2 Stream States

Design for uptime is 1 of many ways to coordinate and converge business goals and expectations with technical goals and expectations
Designing for uptime helps communicate the goals and expectations of a service.
- "But I cannot make my application/service/daemon fast enough"
  - Maybe the service needs to break down in to smaller pieces.
  - Maybe the service is too complicated/complex and needs some rework.
    - This could, also, be another reason to break it down into smaller pieces.
  - Maybe you need to set better expectations.
  - Maybe you should change the terms of the agreement.

Applications that need to set expectations
Applications with customers
- I would define customers in this sense as external consumers of your service/app/daemon
- I would define external consumers as people you service.

Clearly and concisely communicate expectations
- How am I going to get my data?
  - Example:
    - Endpoint: https://service.domain.tld/
    - Path: https://service.domain.tld/path/that/makes/sense/data/would/be/at
    - Port: 443
    - HTTP method: GET
    - AUTH: TOKEN IN HEADER
- How will my data look like?
  - Example:
    - JSON Payload
- How long will each request take?
  - Example:
    - No more than D miliseconds, so long as you ask for this at a rate of E times per F minutes/hours/days
Helps break down services into smaller ones when a problem is too big to resolve it repeatedly in the amount of time required
This also helps communicate expectations to Business leaders.