Patterns – High Availability for Application Architecture Design

Things to keep in Mind

  • This list is a starting point for those who seek to learn about High Availability Architecture Design
  • It is a work in progress and it may get updated from time to time
  • In some places are it is very high level. There are design patterns that are not mentioned here that may fall within another pattern mentioned here. For example, “queues” could fall under the “PUBLISH/SUBSCRIBE” pattern.

1 – Concepts

  • Redundancy
  • Horizontal Auto-scalling
  • Infrastructure as Code
  • Caching
  • Sharding
  • Idempotent Operations
  • Eventual Consistency

2 – Application Implementation

  • Stateless Applications / Web Tier
  • Backend / FrontEnd
  • Publish / Subscribe
  • Micro Services
  • Content Delivery Networks (CDN)
  • Command and Query Responsibility Segregation (CQRS)
  • Event Sourcing
  • Sidecar
  • Strangler

3 – Application Failure Handling

  • Single Point of Failure (Anti-pattern)
  • Timeouts
  • Intermittent and transient errors
  • Circuit Breaking
  • Service degradation & fallbacks
  • Backoff Algorithms
  • Rejection

4 – Operations

  • System Monitoring
  • Immutable Infrastructure
  • Database Replication
  • Distributed Tracing
  • Multiple Data Centers

Are you a solid web engineer? Ask yourself these questions.

This is a question we never asked ourselves because the answer to us is obvious.

In my career I have met 4 types of developers:

  • The Overconfident Hotshot
  • The Uninitiated Newbie
  • The Aimless Developer
  • The Solid Engineer (less often)

The easiest to work with by far is the Solid Engineer. The one that can own a task, works well with others, and everyone is confident the task will not only get done, but it will get done with the highest quality and best time frame possible.

Most of the developers I have work with fall into the Aimless Developer category (myself included at some points in my life). These developers may be good, and in many cases effective, but they generally go through their work with unintentional focus. They treat work as just a job.

I have found that the best way to enjoy any work is to approach it with the following mindset.

“There is always room for improvement”.

This is true for all aspects of life not just web development. When we see ourselves improving it puts us in the state of joy, adding meaning to our lives.

Therefore, when I am working on a project or managing other engineers, these are the questions that I ask myself and of others to assess if I am a Solid Engineer.

Understanding of Context

By context I am referring to: Project goals, Project Process, System Architecture/Frameworks. A Solid Engineer has a good grasp of these 3 within any project. Before a developer starts working, they should have a solid understanding of these 3 aspects in relation to their work.

  • How does my work directly affects the project?
  • Am I following the project process/development guidelines?
  • Do I know the mechanics of the architecture framework?
  • Am I skill enough to work with this technology?
  • Can I offer suggestions on how it can be improved?

Serviceable Code / Maintainability

Well written code offers value in production for years because it is easily maintainable. For this to happen it needs to be easy to understand so that a different future engineer is able to fix and support the code without having to rewrite it. Note: This last point is a hard thing to do, as it is a well known tendency for engineers to think that they can write code better than what was written already.

  • Is my code easy to understand?
    • Legibility over cleverness
    • If the code is easy to understand chances are the developer had a good understanding of what needed to be done.
  • Can it be easily maintained? Simplicity over complexity
  • Is it well documented? Yes, we should write code that self documents, but it helps when we add effective notes that makes it easier to read.

Motivation

Solid Engineers appear to be self powered.

  • What motivates me? Do I have intrinsic motivation?
  • Do I make time learn?

Ownership

A Solid Engineer assumes total responsibility of scope of work and understand that if it does not get done it is their fault.

  • Do I understand the definition of DONE for the task at hand?
  • Do I take full responsibility for the work that needs to be done?
  • Am I willing to accept faults?
  • Do I seek to understand the requirements when I think they are incomplete?
  • Do I expect others to test my code?
  • Am I happy with others looking at my code?
  • Have I asked for any feedback?

Teamwork

A mark of a Solid Engineer knows when to ask for help.

  • Do I seek help from others, or do I seek to be the hero?
  • Do I own too much code?
  • Do I think I can write code better than anyone in the team?
  • Am I setting proactive expectations with others, especially when things are not going well?

Effectiveness / Value

A Solid Engineer focuses on doing the right thing well, instead of doing the wrong thing efficiently.

  • Am I working on the right thing?
  • Do I know what is the 20% of the work that will bring 80% of the value?
  • Do I time-box my tasks in order to minimize time wasted?

Professional Maturity

A Solid Engineer reflects on each experience and seeks to grow in maturity.

  • Do I boasts my own code is always the best?
  • Do I think that I am irreplaceable?
  • Do I take feedback well?
  • Do I often write code that is too complex?
  • Do I say yes to everything that is asked of me without question?
  • Do I make giant commits?