Forem: fatih

Integrating Google OAuth 2.0 with JWT in a Node.js + TypeScript App using Passport.js

fatih — Fri, 03 Jan 2025 11:10:12 +0000

Let’s cut to the chase—auth is a pain. And if you’ve ever used Passport.js, you know it’s not just a pain; it’s a full-blown headache. It’s powerful, yes, but also abstract and sometimes overly complex. But here’s the thing—if you want a solid auth flow, it’s worth the effort. Pair it with Google OAuth 2.0 and JWT, and you’re set with a secure and scalable solution that works. In this article, I’ll show you how to integrate Google OAuth 2.0 into a Node.js app with TypeScript, Passport, and JWT. By the end, you’ll have an auth setup that’s as good as it gets, without the usual "it only works on localhost" issues. Let’s get into it.

Before diving into the implementation, let me make one thing clear—I’m keeping this as real as it gets. We’re not just slapping together a "kinda-real" server; we’re building something solid, with best practices baked in. The goal here isn’t just to show you what to do, but also why we’re doing it. Let’s do this right.

Project Structure

Here’s the file structure, just to give you an idea of how it looks:

google-oauth-jwt-node/  
├── src/  
│   ├── database/  
│   │   ├── models/  
│   │   │   └── User.ts  
│   ├── middlewares/  
│   │   └── requireJwt.ts  
│   ├── auth/  
│   │   ├── google.ts  
│   │   ├── jwt.ts  
│   │   └── passport.ts  
│   ├── routes/  
│   │   └── authRoute.ts  
│   │   └── userRoute.ts  
│   └── app.ts  
├── .env  
├── package.json  
├── tsconfig.json  
├── .gitignore

Let's initialize the project

First, let's create and initialize the Node.js project:

# you may use any name you want
mkdir google-oauth-jwt-node
cd google-oauth-jwt-node

npm init -y

Second, we're going to install the dependencies that we are going to use:

express — Web framework for Node.js.
passport — Authentication middleware for Node.js.
passport-google-oauth20 — Passport strategy for Google OAuth 2.0 authentication.
passport-jwt — Passport strategy for JWT authentication, which will handle verifying JWT tokens.
jsonwebtoken — To generate and verify JWT tokens for authentication.
bcrypt — Library for hashing and comparing passwords.
uuid — For generating unique identifiers (we'll be using it for secure JWT tokens).
dotenv — To load environment variables from a .env file.
ts-node — TypeScript execution environment for running TypeScript files directly.
nodemon — Development tool to automatically restart the server when files change.

Don’t forget to install the @types/ packages as development dependencies for the ones that require them.

To install these, simply run:

# dependencies
npm install express passport passport-google-oauth20 passport-jwt jsonwebtoken bcrypt uuid dotenv

# devDependencies
npm install @types/node @types/express @types/passport @types/passport-google-oauth20 @types/passport-jwt @types/jsonwebtoken @types/bcrypt --save-dev

npm install nodemon typescript ts-node --save-dev

Next, we need to initialize TypeScript:

npx tsc --init

Here’s a simple tsconfig.json configuration:

{
  "compilerOptions": {
    "target": "ES6",
    "module": "CommonJS",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true,
    "outDir": "./dist",
    "baseUrl": "./src"
  },
  "include": ["src/**/*"],
  "exclude": ["node_modules", "dist"]
}

Let's not forget to create .gitignore:

node_modules/
.env
dist/

Add these scripts to your package.json:

"scripts": {
  "dev": "nodemon src/app.ts",        // start in development with automatic restarts
  "build": "tsc"                      // to compile TypeScript
}

Also, put these in your .env file:

GOOGLE_CLIENT_ID=your-google-client-id
GOOGLE_CLIENT_SECRET=your-google-client-secret
JWT_SECRET=your-jwt-secret
# you can change these with whatever you want
BE_BASE_URL=http://localhost:3000
FE_BASE_URL=http://localhost:3001

Getting Google OAuth credentials (Client ID and Secret) is your responsibility. It’s a straightforward process, though it can be overwhelming if you’re unfamiliar with it. There are plenty of guides available online, so I’m not going to go over it here—I'll count on you to figure it out.

Just don't forget to add http://localhost:3000 as Authorized JavaScript origin and add http://localhost:3000/api/auth/google/callback as Authorized redirect URI.

Now we start to implement the project

Here is our app.ts:

// app.ts
import express, { Request, Response } from 'express';
import passport from './auth/passport';  // passport configuration
import dotenv from 'dotenv';
import { json } from 'body-parser';
import authRoute from './routes/authRoute';  // our authRoute
import userRoute from './routes/userRoute';  // our userRoute

// to load environment variables from .env file
dotenv.config();

const app = express();

// middleware to parse json bodies
app.use(json());

// authRoute
app.use('/api/auth', authRoute);

// userRoute
app.use('/api/user', userRoute);

// default route
app.get('/', (req: Request, res: Response) => {
  res.send('welcome to the Google OAuth 2.0 + JWT Node.js app!');
});

// start the server
const PORT = process.env.PORT || 3000;
app.listen(PORT, () => {
  console.log(`server is running on http://localhost:${PORT}`);
});

Then, we start to implement the authentication strategies using Passport. These strategies include Google OAuth 2.0 for authenticating users with their Google accounts and JWT for securing routes with token-based authentication.

src/auth/passport.ts:

// passport.ts
import passport from 'passport';
import { googleStrategy } from './google';
import { jwtStrategy } from './jwt';

// initialize passport with Google and JWT strategies
passport.use('google', googleStrategy);
passport.use('jwtAuth', jwtStrategy);

export default passport;

src/auth/google.ts:

// google.ts
import { Strategy as GoogleStrategy, Profile, VerifyCallback } from 'passport-google-oauth20';
import User from '../database/models/User'; // mock user class
import { v4 as uuidv4 } from 'uuid';

const options = {
  clientID: process.env.GOOGLE_CLIENT_ID || '',
  clientSecret: process.env.GOOGLE_CLIENT_SECRET || '',
  callbackURL: `${process.env.BE_BASE_URL}/api/auth/google/callback`,
};

async function verify(accessToken: string, refreshToken: string, profile: Profile, done: VerifyCallback) {
  try {
    // we check for if the user is present in our system/database.
    // which states that; is that a sign-up or sign-in?
    let user = await User.findOne({
      where: {
        googleId: profile.id,
      },
    });

    // if not
    if (!user) {
      // create new user if doesn't exist
      user = await User.create({
        googleId: profile.id,
        email: profile.emails?.[0]?.value,
        fullName: profile.displayName,
        jwtSecureCode: uuidv4(),
      });
    }

    // auth the User
    return done(null, user);
  } catch (error) {
    return done(error as Error);
  }
}

export default new GoogleStrategy(options, verify);

src/auth/jwt.ts:

// jwt.ts
import { Strategy, ExtractJwt, VerifiedCallback } from 'passport-jwt';
import User from '../database/models/User'; // mock user class
import bcrypt from 'bcrypt';

const options = {
  jwtFromRequest: ExtractJwt.fromAuthHeaderAsBearerToken(),
  secretOrKey: process.env.JWT_SECRET || 'secret-test',
};

async function verify(payload: any, done: VerifiedCallback) {
  /* 
    a valid JWT in our system must have `id` and `jwtSecureCode`.
    you can create your JWT like the way you like.
  */
  // bad path: JWT is not valid
  if (!payload?.id || !payload?.jwtSecureCode) {
    return done(null, false);
  }

  // try to find a User with the `id` in the JWT payload.
  const user = await User.findOne({
    where: {
      id: payload.id,
    },
  });

  // bad path: User is not found.
  if (!user) {
    return done(null, false);
  }

  // compare User's jwtSecureCode with the JWT's `jwtSecureCode` that the 
  // request has.
  // bad path: bad JWT, it sucks.
  if (!bcrypt.compareSync(user.jwtSecureCode, payload.jwtSecureCode)) {
    return done(null, false);
  }

  // happy path: JWT is valid, we auth the User.
  return done(null, user);
}

export default new Strategy(options, verify);

Finally, we’ve set up the necessary strategies for Google OAuth2.0 and JWT authentication and instructed Passport.js to use them in passport.ts.

Now, let’s move on to securing our routes by implementing the requireJwt.ts middleware, which will ensure that access to protected routes is only granted with a valid accessToken.

src/middlewares/requireJwt.ts:

// requireJwt.ts
import passport from '../auth/passport';  // import passport from our custom passport file

// requireJwt middleware to authenticate the request using JWT
const requireJwt = passport.authenticate('jwtAuth', { session: false });

export default requireJwt;

So far, we’ve set up the project, got Google OAuth2.0 and JWT working with Passport.js, and added the middleware to secure routes that need an access token. Now, we’ll implement the necessary endpoints in authRoute.ts to handle Google sign-ins and sign-ups for the app. We’ll also create a mock endpoint GET /api/user/ to return user info, which will only be accessible with a valid access token since we'll be adding our requireJwt.ts middleware in the route.

src/routes/authRoute.ts:

// authRoute.ts
import { Request, Response, Router } from 'express';
import passport from '../auth/passport';  // import passport from our custom passport file
import * as AuthService from '../services/AuthService';  // assuming you have a service

const router = Router();

/*
  This route triggers the Google sign-in/sign-up flow. 
  When the frontend calls it, the user will be redirected to the 
  Google accounts page to log in with their Google account.
*/
// Google OAuth2.0 route
router.get('/google', passport.authenticate('google', { scope: ['profile', 'email'] }));


/*
  This route is the callback endpoint for Google OAuth2.0. 
  After the user logs in via Google's authentication flow, they are redirected here.
  Passport.js processes the callback, attaches the user to req.user, and we handle 
  the access token generation and redirect the user to the frontend.
*/
// Google OAuth2.0 callback route
router.get('/google/callback', passport.authenticate('google', { session: false }), (req: Request, res: Response) => {
  try {
    // we can use req.user because the GoogleStrategy that we've 
    // implemented in `google.ts` attaches the user
    const user = req.user as User;

    // handle the google callback, generate auth token
    const { authToken } = AuthService.handleGoogleCallback({ id: user.id, jwtSecureCode: user.jwtSecureCode });

    // redirect to frontend with the accessToken as query param
    const redirectUrl = `${process.env.FE_BASE_URL}?accessToken=${authToken}`;
    return res.redirect(redirectUrl);
  } catch (error) {
    return res.status(500).json({ message: 'An error occurred during authentication', error });
  }
});

export default router;

src/routes/userRoute.ts:

// userRoute.ts
import { Request, Response, Router } from 'express';
import requireJwt from '../middlewares/requireJwt'; // our middleware to authenticate using JWT
import UserService from '../services/UserService' // assuming you have a service

const router = Router();

// mock user info endpoint to return user data
router.get('/', requireJwt, (req: Request, res: Response) => {
  try {
    /* 
       The requireJwt middleware authenticates the request by verifying 
       the accessToken. Once authenticated, it attaches the User object 
       to req.user (see `jwt.ts`), making it availabe in the subsequent route handlers, 
       like those in userRoute.
    */
    // req.user is populated after passing through the requireJwt 
    // middleware
    const user = req.user as User;

    const veryVerySecretUserInfo = await UserService.getUser({ userId: user.id });

    // it is a mock, you MUST return only the necessary info :)
    return res.status(200).json(veryVerySecretUserInfo);
  } catch (error) {
    return res.status(500).json({ message: 'An error occurred while fetching user info', error });
  }
});

export default router;

But... Fatih... How do I test it?

I hear you saying, "Fatih, this all sounds cool, but how do I know if it actually works?" Don’t worry, I got you. Here's how you can test everything locally: fire up your server, and follow my lead.

We first need to run the server, not actually fire it up... We're not arsonists, right?

Simply type:

npm run dev

and you'll see the output server is running on http://localhost:3000

Now, we just need to open our browser and paste this:

localhost:3000/api/auth/google

and if you did everything right, you'll see this screen;

This is essentially what happens when someone clicks the Sign up with Google button on your frontend.

When you select an account from that list, you’ll be redirected to localhost:3001/?accessToken=${accessToken}. Aaaaaand bada bing bada boom, your frontend will now need to handle this accessToken, save it in localStorage, and send a request to the GET api/user/ endpoint to get the necessary user info. After that, you can authorize the user.

Conclusion

And that’s pretty much it! You've got your Google sign-in and JWT setup working, now you can handle user authentication and authorization in your app. You’ve learned how to set up Passport with Google OAuth2.0, use JWT for session management, and protect routes with a simple middleware.

Next up, it’s just a matter of connecting the dots between the frontend and backend, handling the tokens properly, and giving users a smooth experience. You’re all set to keep building, so go ahead and test it out!

I sincerely thank you for reading through, consider connecting with
me on;

youtube
x
linkedin
my personal website - fatihguzel.dev

Backend Red Flags - What NOT to do

fatih — Mon, 23 Dec 2024 18:55:14 +0000

Standarts are there for us to maintain. By doing so, you stand a high chance of getting a GOOD software artifact in the end. However it's not guaranteed; the things that you commit may be ruining the quality of your artifact.

In this article, we will go through, step-by-step, some of the most well-known yet still not fully understood red flags in backend development, anti-patterns.

1. Never write BUSINESS LOGIC in a Controller

I'm going to say this one time, only one time, do your best to understand:

CONTROLLERS ARE ONLY THERE TO HANDLE REQUESTS AND RESPONSES.

Business Logic must be placed either in a separate contextService.file or in a module that is apart from the controller. This is MOST PROBABLY a must for you to agree upon no matter what. There may be, I'm saying "may", some cases that you think require such action; most of the time, they're avoidable. In other words, you're doing something WRONG.

Let's look at to it with an example, to make things clearer:

Bad Example

import { Request, Response } from 'express';
import bcrypt from 'bcrypt';
import { UserModel } from './models/User';

export class UserController {
  public async createUser(req: Request, res: Response): Promise<Response> {
    try {
      const { username, password } = req.body;

      // business logic put inside the controller
      const hashedPassword = await bcrypt.hash(password, 10);
      const newUser = await UserModel.create({ username, password: hashedPassword });

      return res.status(201).json(newUser);
    } catch (error) {
      return res.status(500).json({ message: 'Error creating user' });
    }
  }
}

Why this is bad?

The controller is too bloated because it mixes request handling with business logic.
Reusing the hashing or user creation logic elsewhere becomes difficult.
Testing the controller becomes harder, as you'd need to mock business logic in your tests.

Good Example

// UserService.ts
import bcrypt from 'bcrypt';
import { UserModel } from './models/User';

export class UserService {
  public async createUser(username: string, password: string): Promise<any> {
    // business logic is encapsulated here
    const hashedPassword = await bcrypt.hash(password, 10);
    return UserModel.create({ username, password: hashedPassword });
  }
}

// UserController.ts
import { Request, Response } from 'express';
import { UserService } from './services/UserService';

export class UserController {
  private userService = new UserService();

  public async createUser(req: Request, res: Response): Promise<Response> {
    try {
      const { username, password } = req.body;

      // delegate logic to the service
      const newUser = await this.userService.createUser(username, password);

      return res.status(201).json(newUser);
    } catch (error) {
      return res.status(500).json({ message: 'Error creating user' });
    }
  }
}

Why this is good?

Separation of Concerns

The controller focuses only on handling requests and responses. Business logic is isolated in a dedicated service class, making it easier to manage.

Reusability

The service logic can now be reused in other parts of your artifact (e.g., another controller, a background job).

Testability

You can now write separate unit tests for the UserService.ts and UserController. Mocking and testing become much simpler.

2. Neglecting DTOs for Data Exposure (Sensitive Data Leak)

DTOs ARE ESSENTIAL FOR SECURING THE DATA YOU EXPOSE.

Without DTOs, you risk EXPOSING sensitive data you shouldn’t. You may think it's okay to return raw database objects or use models directly, but most of the time, you're just ASKING FOR TROUBLE.

Sensitive fields like passwords, tokens, and personal information should never be exposed in a response unless absolutely necessary. It’s your job to prevent that, using DTOs to clean and filter the data.

If you skip this, YOU'RE ASKING FOR A DATA LEAK.

Let's look at an example to make it crystal clear:

Bad Example

import { Request, Response } from 'express';
import { UserModel } from './models/User';

export class UserController {
  public async getUser(req: Request, res: Response): Promise<Response> {
    try {
      const userId = req.params.id;

      // fetch user directly from the database also business logic inside the controller
      const user = await UserModel.findById(userId);

      if (!user) {
        return res.status(404).json({ message: 'User not found' });
      }

      // Returning raw data (contains sensitive fields like password)
      return res.json(user);
    } catch (error) {
      return res.status(500).json({ message: 'Error fetching user' });
    }
  }
}

Why this is bad?

Sensitive Data Exposure

The raw user object might include sensitive fields like password, isAdmin, or createdAt, which should not be exposed to the frontend.

Lack of Control

There’s no control over which fields are exposed in the response. The entire object is sent, which could lead to security issues or unnecessary data being leaked.

Good Example

// UserDTO.ts
export class UserDTO {
  constructor(public id: string, public username: string, public email: string) {}

  // static method to map the user entity to a DTO
  public static fromEntity(user: any): UserDTO {
    return new UserDTO(user._id, user.username, user.email);
  }
}

// UserController.ts
import { Request, Response } from 'express';
import { UserModel } from './models/User';
import { UserDTO } from './dtos/UserDTO';

export class UserController {
  public async getUser(req: Request, res: Response): Promise<Response> {
    try {
      const userId = req.params.id;

      // fetch user directly from the database
      const user = await UserModel.findById(userId);

      if (!user) {
        return res.status(404).json({ message: 'User not found' });
      }

      // map user entity to DTO
      const userDTO = UserDTO.fromEntity(user);

      // return the controlled user DTO, not raw data
      return res.json(userDTO);
    } catch (error) {
      return res.status(500).json({ message: 'Error fetching user' });
    }
  }
}

Why this is good?

Only the necessary fields are included in the DTO, preventing sensitive data exposure.

3. Never Use Synchronous Code in Async Operations

This one’s simple: NEVER mix synchronous code in asynchronous operations. It’s like trying to run a marathon with a broken leg—it's going to SLOW YOU DOWN.

When you write asynchronous code, you’re telling the system, “Hey, go ahead and do this task while I get other stuff done.” If you suddenly throw synchronous code into the mix, you're blocking the entire process. It’s like a traffic jam on a highway—everything else has to wait for that one slow-moving car to get out of the way.

Why does this matter?
When you use synchronous operations (like fs.readFileSync or JSON.parse()), you're forcing the system to halt while that operation completes, preventing other tasks from being processed. This becomes especially dangerous in a highly concurrent environment like web servers, where latency can directly impact the user experience.

NEVER do this if you want your system to scale and respond quickly. Stick to asynchronous methods, and you'll keep your app smooth, fast, and efficient.

Let’s see this with a code example:

Bad Example

// UserProfileService.ts
import fs from 'fs';
import { UserProfile } from '../models/UserProfile';

export class UserProfileService {
  public async getUserProfile(userId: string): Promise<UserProfile> {
    try {
      // synchronous operation: this blocks the event loop until the file is fully read
      const data = fs.readFileSync(`./data/users/${userId}.json`, 'utf-8');

      // parse JSON data and return the user profile
      const userProfile: UserProfile = JSON.parse(data);
      return userProfile;
    } catch (error) {
      throw new Error('User profile not found');
    }
  }
}

Why this is bad?

Blocking the Event Loop

fs.readFileSync() is synchronous, so when the server reads a file, it blocks the event loop. While reading one user's profile, other incoming requests have to wait. This is a major performance bottleneck.

Scalability Problems

If multiple users are trying to fetch their profile simultaneously, each request would block the server, causing a queue of requests and increasing response time. The server can handle fewer requests per second, leading to poor user experience.

Good Example

// UserProfileService.ts
import fs from 'fs/promises';
import { UserProfile } from '../models/UserProfile';

export class UserProfileService {
  public async getUserProfile(userId: string): Promise<UserProfile> {
    try {
      // asynchronous operation: non-blocking, doesn't hold up the event loop
      const data = await fs.readFile(`./data/users/${userId}.json`, 'utf-8');

      // parse JSON data and return the user profile
      const userProfile: UserProfile = JSON.parse(data);
      return userProfile;
    } catch (error) {
      throw new Error('User profile not found');
    }
  }
}

Why this is good?

Non-Blocking

Using fs.readFile() from the fs/promises module makes the file reading operation asynchronous. The await ensures that while waiting for the file to be read, other tasks (such as responding to different HTTP requests) are processed without any delay.

Scalable

Since the event loop isn't blocked, the server can handle many concurrent requests efficiently. If multiple users request their profiles at the same time, the server can continue serving other requests while it waits for each file to be read.

Better User Experience

Users won't experience delays due to blocking, leading to faster response times and a better overall user experience.

4. Too Generic Error Handling- A Debugging Nightmare

Let’s talk about one of the most frustrating mistakes you can make when dealing with errors in your application: Too Generic Error Handling. You’ve probably encountered this before—errors that are too vague or too repetitive to be useful. When you catch errors and just throw or log a generic message like "Something went wrong" or "An error occurred", you’re essentially making debugging harder for yourself and your team. Context is everything, and a generic error message will only leave you guessing what actually went wrong. Debugging should be about tracing the root cause, not staring at the same meaningless message over and over again.

Let’s explore why this happens and how you can avoid it with better error handling:

Bad Example

// PaymentService.ts
import axios from 'axios';

export class PaymentService {
  private paymentAPI = 'https://paymentgateway.com/api/payment';

  // method to process payment
  public async processPayment(userId: string, amount: number): Promise<boolean> {
    try {
      const response = await axios.post(this.paymentAPI, { userId, amount });

      if (response.data.success) {
        return true;
      } else {
        throw new Error('Payment failed');
      }
    } catch (error) {
      // catch all errors and print a generic message
      console.error('An error occurred during payment processing');
      return false;
    }
  }
}

Why this is bad?

No Error Context

The error handling is generic and does not provide any useful information about the nature of the failure. It doesn't account for different types of errors that may occur (e.g., network errors, API-specific errors, or user-related errors).

Repetitive Message

The same message ("An error occurred during payment processing") is logged regardless of the actual issue. This leads to repetitive and uninformative error logs that make debugging much harder.

Good Example

// PaymentService.ts
import axios from 'axios';

export class PaymentService {
  private paymentAPI = 'https://paymentgateway.com/api/payment';

  // method to process payment
  public async processPayment(userId: string, amount: number): Promise<boolean> {
    try {
      const response = await axios.post(this.paymentAPI, { userId, amount });

      if (response.data.success) {
        return true;
      } else {
        // handle API-specific failure scenarios
        if (response.data.errorCode === 'INSUFFICIENT_FUNDS') {
          throw new Error('Payment failed due to insufficient funds');
        } else if (response.data.errorCode === 'INVALID_CARD') {
          throw new Error('Payment failed due to invalid card');
        } else {
          throw new Error('Payment failed due to an unknown error');
        }
      }
    } catch (error: any) {
      // check if it's a network or server error
      if (error.response) {
        console.error(`Payment failed with status ${error.response.status}: ${error.response.data.message}`);
      } else if (error.request) {
        console.error('Payment request failed: No response from payment gateway');
      } else {
        console.error(`Payment failed: ${error.message}`);
      }
      return false;
    }
  }
}

Why this is good?

Specific Error Handling

The code checks for specific error codes like INSUFFICIENT_FUNDS or INVALID_CARD to provide clear, targeted messages.

Actionable Error Messages

The system gives clear, actionable messages that help users and developers understand and fix the issue.

Error Categorization

The code distinguishes between different error types (e.g., network, API errors) to handle them appropriately.

Transparent Debugging

Detailed logs make it easy to pinpoint exactly where and why the error happened.

Conclusion

Well, these are some of the most common red flags I've encountered over the years in software development. Don’t feel bad if you've fallen into these traps—there's always room to improve. Just take the time, learn from it, which will help you to become best version of yourself over the time.

I sincerely thank you for reading through, consider connecting with
me on;

youtube
x
linkedin
my personal website - fatihguzel.dev

HA, FT, DR; What they mean and Why they matter?

fatih — Thu, 19 Dec 2024 09:21:59 +0000

It all starts with a thought, how can I improve my infrastructure? There are plenty of other things you should care about, but these terms are probably the most important ones.

High Availability, Fault Tolerance and Disaster Recovery.

In this article, you'll find enough answers to start caring about resilience, hopefully. Let's start with explaining terms.

What is High Availability (HA)?

High Availability ensures a defined level of operational performance is consistently maintained. It's not about enhancing the user experience though, not the aim but the result.

It may sound a bit confusing, so let's explain it in much simpler terms;

High Availability is about maximizing the system's online time, at the same time minimizing the outages. A system can fail anytime, but you can also replace the component that causes the system to fail in order to fix the issue, fast. You might say "hey fatih, why don't we diagnose the issue and fix it?". The answer is simple, our aim is to maximize UPTIME of the system. The time it takes to analyze the situation, diagnose the issue, and implement a fix affects the system's uptime. The approach is simple, "it is better alive than dead".

How to measure High Availability?

With 9's of course.

High Availability is measured with percentages;

Three 9's (99.9%) -> It means the system is up 99,9% of the year. In other words the system is down for 8.77 hours per year.

Five 9's (99.999%) -> down for 5.26 minutes per year.

In summary;

HA is about maximizing the system UPTIME.
It requires additional costs and extra planning.

What is Fault Tolerance (FT)?

Fault Tolerance and High Availability often get confused with each other. While HA is about the system uptime, Fault Tolerance ensures a system continues to operate correctly even when some components fail. A system that operates through even failure. Fault Tolerance (FT) requires redundant systems that operate simultaneously to take over during an outage in the primary system., which multiplies the costs.

It is not a simple fail-over system; therefore, it is much more complex than HA. It is harder to design and implement and requires much more detailed planning and engineering. This is because we aim for 100% UPTIME now, where even a minute or second of downtime is TOO MUCH to lose.

In April 2011, AWS faced a major outage when a failure in its Elastic Block Store (EBS) disrupted services for many customers. However, AWS's fault-tolerant design kicked in. Data was replicated across multiple servers, so even though some systems went down, most services kept running. Customers were able to continue operations with minimal disruption, proving the strength of AWS’s redundancy and recovery systems.

What is Disaster Recovery (DR)?

Disaster Recovery refers to a set of policies, tools, and procedures designed to enable the recovery or continuation of critical infrastructure after a disaster. DR is a process. It is the ability to restore access and functionality to the infrastructure after a disaster.

Think of it as a pilot ejection system in a jet.

In many cases, Disaster Recovery can be automated for efficiency.

Conclusion

In the end, building up a resilient system is all about connecting the dots. That easy huh? HA, FT, DR are just cornerstones for your infrastructure. Keep these principles in mind as you improve your infrastructure, and you'll be better prepared for whatever comes your way.

I sincerely thank you for reading through, consider connecting with
me on;

youtube
x
linkedin