When working with a binary tree, the real question isn't just how to move through its nodes — it's in what order you choose to visit them.

There are three fundamental depth-first search (DFS) traversals:

• Preorder

• Inorder

• Postorder

All three share the exact same recursive skeleton. The only thing that changes between them is when the current node gets processed relative to its subtrees.

Table of Contents

• The Basic Rule

• Preorder Traversal

• The Recursion Intuition

• Inorder Traversal

• Postorder Traversal

• Side-by-Side Comparison

• Time & Space Complexity

• How to Remember Them

The Basic Rule

Before comparing the three traversals, internalize one rule that never changes:

We always move left to right — left subtree before right subtree.

The only variable is where the current node is processed relative to that left-to-right movement:

Preorder   →  Root → Left → Right
Inorder    →  Left → Root → Right
Postorder  →  Left → Right → Root

Once you see where the root falls in each pattern, all three become trivial to derive on the spot — no memorization required.

We'll use this tree as a running example throughout:

        1
       / \
      2   3
     / \
    4   5

Preorder Traversal

Order: Root → Left → Right

At each node:

1. Visit the current node.

2. Traverse the left subtree.

3. Traverse the right subtree.

Walkthrough:

1. Start at 1 — it's the root, so process it first.

2. Descend into the left subtree rooted at 2. Process 2, then its left child 4 (no children → return), then its right child 5.

3. With the entire left subtree of 1 finished, move to the right subtree, 3.

Result:

1 → 2 → 4 → 5 → 3

The Recursion Intuition

This is the part that makes traversals click.

Every time recursion descends into a child, that child becomes the root of a smaller subtree — and the exact same rule (Root → Left → Right) applies again, just at a smaller scale.

        1
       /
      2
     /
    4

When recursion reaches 2, it doesn't need new logic — it just re-applies Root → Left → Right:

2 → 4 → ...

And at 4, both children are null, so the call returns immediately and control unwinds back up the call stack. This self-similar structure is exactly why recursion maps so naturally onto trees.

Preorder — C++

class Solution {
public:
    void preOrder(TreeNode* root, vector<int>& ans) {
        if (root == nullptr)
            return;

        ans.push_back(root->val);   // process root first

        preOrder(root->left, ans);
        preOrder(root->right, ans);
    }
};

vector<int>& ans is passed by reference, so every recursive call accumulates into the same result vector rather than building separate copies.

Preorder — Java

class Solution {
    public void preOrder(TreeNode root, List<Integer> ans) {
        if (root == null)
            return;

        ans.add(root.val);   // process root first

        preOrder(root.left, ans);
        preOrder(root.right, ans);
    }
}

The shape of the logic is identical:

Process Root → Traverse Left → Traverse Right

Inorder Traversal

Order: Left → Root → Right

Only one thing changes from preorder — when the root is processed:

1. Traverse the left subtree.

2. Visit the current node.

3. Traverse the right subtree.

Using the same tree, the result is:

4 → 2 → 5 → 1 → 3

Compare the two so far:

Preorder:  1 → 2 → 4 → 5 → 3
Inorder:   4 → 2 → 5 → 1 → 3

The tree hasn't changed. The recursive calls haven't changed. Only the position of the root's processing line moved.

Inorder — C++

class Solution {
public:
    void inOrder(TreeNode* root, vector<int>& ans) {
        if (root == nullptr)
            return;

        inOrder(root->left, ans);

        ans.push_back(root->val);   // process root in the middle

        inOrder(root->right, ans);
    }
};

Compared to preorder, ans.push_back(root->val) simply moved between the two recursive calls.

Inorder — Java

class Solution {
    public void inOrder(TreeNode root, List<Integer> ans) {
        if (root == null)
            return;

        inOrder(root.left, ans);

        ans.add(root.val);   // process root in the middle

        inOrder(root.right, ans);
    }
}

Traverse Left → Process Root → Traverse Right

Postorder Traversal

Order: Left → Right → Root

The root is processed only after both subtrees are fully traversed:

1. Traverse the left subtree.

2. Traverse the right subtree.

3. Visit the current node.

Using the same tree, the result is:

4 → 5 → 2 → 3 → 1

Again — same tree, same recursive calls, only the root's processing line moved, this time to the very end.

Postorder — C++

class Solution {
public:
    void postOrder(TreeNode* root, vector<int>& ans) {
        if (root == nullptr)
            return;

        postOrder(root->left, ans);
        postOrder(root->right, ans);

        ans.push_back(root->val);   // process root last
    }
};

Postorder — Java

class Solution {
    public void postOrder(TreeNode root, List<Integer> ans) {
        if (root == null)
            return;

        postOrder(root.left, ans);
        postOrder(root.right, ans);

        ans.add(root.val);   // process root last
    }
}

Traverse Left → Traverse Right → Process Root

Side-by-Side Comparison

Time & Space Complexity

All three traversals share the same complexity profile, since each visits every node exactly once:

• Time complexity: O(n), where n is the number of nodes.

• Space complexity: O(h) for the recursion call stack, where h is the height of the tree.

  • Balanced tree → O(log n).

  • Skewed (degenerate) tree → O(n), since the call stack depth equals the number of nodes.

Note that the output list itself also takes O(n) space, independent of the traversal order.

How to Remember Them

You don't need to memorize three separate algorithms — just the meaning of the prefixes:

• PREorder — pre = before → the root comes first: Root → Left → Right

• INorder — in = in between → the root comes in the middle: Left → Root → Right

• POSTorder — post = after → the root comes last: Left → Right → Root

Combine that with the one constant rule — left always comes before right — and the entire family of traversals collapses into a single idea:

PRE   → ROOT first
IN    → ROOT in the middle
POST  → ROOT last

Level Order Traversal: Why We Walk Trees Breadth-First

When you're asked to process a tree level by level — floor by floor, row by row, nearest nodes first — the depth-first instinct that works for so many other tree problems stops being useful. This is where Level Order Traversal, powered by Breadth-First Search (BFS), comes in.

The Problem: Depth vs. Breadth

Take this tree:

             1
           /   \
          2     3
         / \   / \
        4   5 6   7

A depth-first traversal would go something like 1 → 2 → 4 → 5 → 3 → 6 → 7, diving as far down one branch as it can before backtracking.

A level-order (breadth-first) traversal instead visits every node on a given level before moving to the next:

Level 0: 1
Level 1: 2 → 3
Level 2: 4 → 5 → 6 → 7

An Analogy: The Building Cleaner

Imagine a cleaner working through a multi-story building. They don't jump between floors at random — they finish the entire first floor, then move to the second, then the third. That's exactly the discipline level order traversal enforces: finish the current level before starting the next one.

Why a Queue?

The trick that makes this traversal work is a queue, because a queue is First In, First Out (FIFO) — the same order in which we discover nodes is the order in which we should process them.

The algorithm, in five steps:

1. Push the root onto the queue.

2. While the queue isn't empty, record how many nodes are currently in it — that number is the size of this level.

3. Dequeue that many nodes, one at a time, appending each node's value to the current level's result and enqueuing its left and right children (if they exist).

4. Once you've dequeued exactly that many nodes, the level is complete — push the level's array onto the final result.

5. Repeat until the queue is empty.

Walking Through an Example

Using the same tree:

             1
           /   \
          2     3
         / \   / \
        4   5 6   7

The final result:

[
  [1],
  [2, 3],
  [4, 5, 6, 7]
]

Why a for Loop Inside the while Loop?

This is the detail that trips most people up the first time. Before processing a level, we snapshot the queue's current size:

int levelSize = q.size();

Then we loop exactly that many times:

for (int i = 0; i < levelSize; i++) {
    // process current level
}

Why snapshot the size instead of just looping while (!q.isEmpty())? Because while we process nodes on the current level, we're also enqueuing their children — and those children belong to the next level. Without capping the loop at levelSize, we'd start processing children before the current level was finished, and the level boundaries would collapse.

By fixing levelSize up front, we guarantee the for loop touches only the nodes that existed in the queue before any children were added — exactly the current level, nothing more.

The Core Pattern

Once this clicks, the whole problem collapses into one chain of reasoning:

Level-by-level traversal
        ↓
       BFS
        ↓
      Queue
        ↓
Process queue one level at a time
        ↓
Store each level separately

Whenever a problem talks about trees in terms of:

• level by level

• row by row

• floor by floor

• nearest node/level first

...that's your signal to reach for BFS with a queue, not recursion or a stack.

Complexity

Time — O(n). Every node is enqueued and dequeued exactly once.

Space — O(n). In the worst case (a wide, shallow tree), the queue can hold an entire level's worth of nodes — up to roughly n/2 for a complete binary tree — and the result array stores all n node values.

Reference Implementation

Java

public List<List<Integer>> levelOrder(TreeNode root) {
    List<List<Integer>> result = new ArrayList<>();
    if (root == null) return result;

    Queue<TreeNode> queue = new LinkedList<>();
    queue.offer(root);

    while (!queue.isEmpty()) {
        int levelSize = queue.size();
        List<Integer> currentLevel = new ArrayList<>();

        for (int i = 0; i < levelSize; i++) {
            TreeNode node = queue.poll();
            currentLevel.add(node.val);

            if (node.left != null)  queue.offer(node.left);
            if (node.right != null) queue.offer(node.right);
        }

        result.add(currentLevel);
    }

    return result;
}

Python

from collections import deque

def level_order(root):
    result = []
    if not root:
        return result

    queue = deque([root])

    while queue:
        level_size = len(queue)
        current_level = []

        for _ in range(level_size):
            node = queue.popleft()
            current_level.append(node.val)

            if node.left:
                queue.append(node.left)
            if node.right:
                queue.append(node.right)

        result.append(current_level)

    return result

Where This Pattern Shows Up Again

Once level order traversal is second nature, a whole family of tree problems becomes a small variation on the same skeleton:

• Zigzag level order — alternate the direction you append values in, left-to-right then right-to-left.

• Right side view — keep only the last node processed in each level.

• Level averages / sums — accumulate a running total instead of a list per level.

• Minimum depth — return as soon as you dequeue a node with no children.

The Main Takeaway

Don't memorize the code — memorize the trigger. The moment a tree problem asks you to think in terms of levels, the chain is always the same:

Level Order → BFS → Queue

Once that association is automatic, the implementation writes itself.

From Roles and Permissions to Resource-Level Authorization

While building a multi-role College ERP, I ran into an authorization problem that initially looked simple but became much more complicated as the system grew.

In a typical application, we usually start with something like:

USER
ADMIN
SUPER_ADMIN

Then authorization is straightforward:

if (user.role === "ADMIN") {
  // allow
}

But a College ERP is very different.

There can be many different types of users:

• Student

• Faculty

• HOD

• Clerk

• Accountant

• Exam Officer

• Admission Officer

• Principal

• Director

• Secretary

• Super Admin

And the important part is that these roles are not necessarily fixed forever.

The institution may need to create a new role later.

For example:

• Lab Coordinator

• Library Administrator

• Department Coordinator

• Placement Officer

• Hostel Warden

So the real question was no longer:

"What role does this user have?"

It became:

"What is this role allowed to do?"

And then an even harder question appeared:

"What is this role allowed to do, on which resource, and under what conditions?"

That is where I started moving from simple role-based checks toward a proper roles → permissions → resource-level authorization model.

The Problem With Traditional Role Checks

My first thought was to define roles directly in the application:

enum Role {
  STUDENT,
  FACULTY,
  HOD,
  PRINCIPAL,
  ADMIN,
  SUPER_ADMIN
}

Then I could simply check:

if (user.role === "FACULTY") {
  // faculty access
}

This works initially.

But imagine the ERP grows.

Now we have 20 roles.

And each role needs different access.

For example:

Now the code starts becoming:

if (
  user.role === "ADMIN" ||
  user.role === "PRINCIPAL" ||
  user.role === "HOD"
) {
  // allow
}

Then another requirement arrives:

Faculty should be able to create something, but only for their department.

Now the role itself isn't enough.

We need to know:

Who is the user?
        ↓
What role do they have?
        ↓
What permissions does that role have?
        ↓
Which resource are they accessing?
        ↓
Are they allowed to access THIS resource?

That changed how I thought about authorization.

Roles Should Not Define Everything

One of the important decisions I made was separating roles from permissions.

Instead of thinking:

Faculty = Can do X
HOD = Can do Y
Admin = Can do Z

I started thinking:

Role
  ↓
Permissions
  ↓
Resources

For example:

FACULTY
   │
   ├── student.read
   ├── attendance.read
   ├── attendance.create
   └── attendance.update

While:

HOD
   │
   ├── student.read
   ├── student.create
   ├── student.update
   ├── attendance.manage
   ├── faculty.read
   └── reports.read

And:

ACCOUNTANT
   │
   ├── student.read
   ├── fees.read
   ├── fees.create
   ├── fees.update
   └── financial-reports.read

Now the role is simply a collection of permissions.

The Interesting Problem: Roles Can Be Created Dynamically

This was one of the bigger requirements in my ERP.

I didn't want to hard-code every possible role into the backend.

For example, I didn't want this:

enum Role {
  STUDENT,
  FACULTY,
  HOD,
  CLERK,
  ACCOUNTANT,
  PRINCIPAL,
  SUPER_ADMIN
}

because tomorrow the institution might need:

• Placement Officer

• Department Coordinator

• Hostel Warden

I wanted the system to support:

Create Role
      ↓
Select Permissions
      ↓
Save Role
      ↓
Assign Role to Users

So a role becomes data stored in the database rather than something that has to be added to the source code every time.

For example:

Role: Department Coordinator

Permissions:

student.read
student.update
attendance.read
attendance.update
reports.read

The backend doesn't need a new DEPARTMENT_COORDINATOR enum just to support it.

But Then Another Problem Appeared

If roles can be created dynamically, who is allowed to create a role?

This is where authorization becomes interesting.

Suppose a Faculty member sends:

POST /api/roles

with:

{
  "name": "Super Admin"
}

Should the backend allow it?

Obviously, the answer depends on the permissions assigned to that faculty member.

So checking:

user.role === "FACULTY"

isn't enough.

We need something closer to:

User
 ↓
Role
 ↓
Permissions
 ↓
Can this permission be executed?

For example:

role.create

Now the API can ask:

Does this user have role.create permission?

instead of asking:

Is this user an admin?

That is a much more flexible model.

Permissions as Actions

I decided to think about permissions as an action performed on a resource.

A simple format is:

resource.action

For example:

student.read
student.create
student.update
student.delete

faculty.read
faculty.create
faculty.update
faculty.delete

role.read
role.create
role.update
role.delete

attendance.read
attendance.create
attendance.update

fees.read
fees.create
fees.update

This gives the authorization system a consistent vocabulary.

Instead of writing:

if (user.role === "ADMIN") {
   // ...
}

the application can ask:

hasPermission(user, "role.create");

That makes the authorization logic much easier to reason about.

The Architecture

The basic relationship becomes:

                    USER
                      │
                      ↓
                    ROLE
                      │
                      ↓
                PERMISSIONS
                      │
                      ↓
                  RESOURCE

Or, if a user can have multiple roles:

                    USER
                     │
             ┌───────┴───────┐
             ↓               ↓
          FACULTY            HOD
             │               │
             └───────┬───────┘
                     ↓
               PERMISSIONS
                     │
                     ↓
                  RESOURCE

For example:

User: Rahul

Roles:
    Faculty
    Department Coordinator

Effective permissions:

    student.read
    student.update
    attendance.read
    attendance.update
    reports.read

The user's effective permissions can be derived from all assigned roles.

But RBAC Still Wasn't Enough

This is where the problem became more interesting.

Imagine a Faculty member has:

student.read
student.update

Does that mean they can update every student in the college?

Probably not.

A faculty member may only be responsible for students in their department.

For example:

Faculty
Department: Information Technology

Student:

Student A
Department: Information Technology

Allowed.

But:

Student B
Department: Computer Science

Maybe not allowed.

Now permission alone isn't enough.

We need to consider the resource itself.

The authorization decision becomes:

Does the user have the permission?
                +
Does the user have access to this resource?

This is where I started thinking about resource-level authorization.

From RBAC to Resource-Level Authorization

Instead of:

Can Faculty update students?

the question becomes:

Can this Faculty member update THIS student?

For example:

const hasPermission =
  user.permissions.includes("student.update");

const sameDepartment =
  user.departmentId === student.departmentId;

if (!hasPermission || !sameDepartment) {
  throw new ForbiddenError();
}

Now authorization considers both:

Permission
+
Resource context

This is much closer to how a real ERP needs to work.

Why This Matters

Consider an HOD.

An HOD might have:

student.read
student.create
student.update

But their authority could be limited to their own department.

So:

HOD
 │
 ├── student.update
 │
 └── Department = Information Technology

When the HOD requests:

PATCH /students/123

the backend should not simply check:

hasPermission("student.update");

It should also determine:

Student 123
     ↓
Which department?
     ↓
Does HOD have authority over that department?

The final decision becomes:

Permission ✓
        +
Resource Scope ✓
        ↓
      ALLOW

Otherwise:

Permission ✓
        +
Resource Scope ✗
        ↓
      DENY

The Authorization Pipeline

The architecture I started moving toward looks like this:

HTTP Request
     │
     ↓
Authentication
     │
     ↓
Identify User
     │
     ↓
Load Roles
     │
     ↓
Resolve Permissions
     │
     ↓
Permission Check
     │
     ↓
Resource-Level Check
     │
 ┌───┴────┐
 ↓        ↓
ALLOW    DENY
 ↓        ↓
Service   403
 ↓
Database

This gives each layer a clear responsibility.

Authentication answers:

Who is this user?

Permission check answers:

Is this user allowed to perform this action?

Resource authorization answers:

Is this user allowed to perform this action on this particular resource?

One of the Most Important Lessons

The biggest lesson for me was that roles should not be treated as permissions.

A role is a grouping mechanism.

A permission represents an allowed action.

And resource-level authorization determines whether that action is valid for a particular resource or context.

So instead of:

Faculty → Can update students

the model becomes:

Faculty
   ↓
student.update
   ↓
Student #123
   ↓
Department / ownership / scope check
   ↓
ALLOW or DENY

That separation makes the system much easier to extend.

If tomorrow I create:

Placement Officer

I don't need to change authorization logic everywhere.

I can create the role and assign:

student.read
placement.create
placement.update
placement.read
reports.read

The same authorization engine can continue working.

Where I Am Taking This Architecture

For a College ERP, I don't want authorization to become a collection of:

if (role === ...)

statements scattered across controllers.

I want it to become a consistent system:

User
  ↓
Roles
  ↓
Permissions
  ↓
Resource Scope
  ↓
Authorization Decision

This gives the ERP room to grow from a handful of roles to dozens of roles without having to redesign authorization every time a new administrative responsibility appears.

And that was the real shift in my thinking:

I wasn't really trying to design roles. I was designing an authorization system.

That distinction became important once the application started dealing with multiple departments, multiple resources, dynamically created roles, and different levels of access.

While building a custom authentication system with Google OAuth, GitHub OAuth, and traditional email/password authentication, I encountered an interesting problem:

How can we allow the same user to authenticate through multiple providers without creating duplicate accounts or treating each provider as a separate user?

Initially, my authentication system treated each authentication method independently. This worked when a user consistently used the same provider, but caused problems when the same user switched providers.

The Problem I Encountered

Consider this scenario.

A user visits the application for the first time and chooses:

Continue with Google

Google authenticates the user and returns information such as:

• Email

• Name

• Profile picture

• Google account ID

The application creates a user account:

┌─────────────────────────────┐
│            User             │
├─────────────────────────────┤
│ id:    usr_123              │
│ email: user@example.com     │
│ name:  John Doe             │
└─────────────────────────────┘

Everything works.

The next day, the same user visits the application but chooses:

Continue with GitHub

GitHub returns:

• Email: user@example.com

• GitHub Account ID: github_98765

The application checks the database and finds user@example.com.

Because that email already exists, the system returns:

Email already linked

From the application's perspective, this seems reasonable.

But from the user's perspective, it is incorrect.

The user is still the same person. They simply used a different authentication provider.

The Real Problem

The initial architecture was effectively treating authentication providers as separate users:

          Authentication
                │
       ┌────────┼────────┐
       ↓        ↓        ↓
    Google    GitHub   Password
       │        │        │
       ↓        ↓        ↓
     User     User     User

What we actually need is:

                    ┌──────────────┐
                    │     User     │
                    │   usr_123    │
                    └──────┬───────┘
                           │
              ┌────────────┼────────────┐
              ↓            ↓            ↓
          Google         GitHub      Password
          Identity       Identity    Credential

The important distinction is:

A user account is not the same thing as an authentication method.

OAuth and Custom Authentication Work Differently

One of the things that made this problem interesting is that OAuth authentication and traditional email/password authentication have different flows.

OAuth Authentication

With Google or GitHub, the OAuth provider handles the authentication process.

The basic flow looks like this:

┌──────────┐
│   User   │
└────┬─────┘
     │
     │ Continue with Google/GitHub
     ↓
┌──────────────┐
│ OAuth        │
│ Provider     │
└────┬─────────┘
     │
     │ Authenticate user
     ↓
┌──────────────────────┐
│ Application Callback │
└──────────┬───────────┘
           │
           │ Provider identity
           ↓
      Find/Create User
           │
           ↓
      Create Session
           │
           ↓
       Application

Therefore, OAuth can effectively handle both registration and login through the same flow.

If the user doesn't exist:

OAuth
  ↓
User doesn't exist
  ↓
Create User
  ↓
Create Identity
  ↓
Create Session
  ↓
Application

If the user already exists:

OAuth
  ↓
User exists
  ↓
Authenticate
  ↓
Create Session
  ↓
Application

The user doesn't necessarily need separate:

• Register with Google

• Login with Google

buttons.

The application can determine whether the authenticated identity already exists.

Traditional Email/Password Authentication

Custom authentication usually has separate flows.

Registration

User
  ↓
Registration Page
  ↓
Email + Password
  ↓
Validate Input
  ↓
Hash Password
  ↓
Create User
  ↓
Create Password Credential

Login

User
  ↓
Login Page
  ↓
Email + Password
  ↓
Verify Credentials
  ↓
Create Session
  ↓
Application

The exact flow depends on the application's business requirements.

Authentication vs Profile Completion

Another problem appears when OAuth does not provide all the information required by the application.

For example, Google might provide:

• Email

• Name

• Profile Picture

• Google Account ID

But the application might require:

• Phone Number

• Department

• Organization

• Date of Birth

• Address

Those fields cannot simply be expected from the OAuth provider.

Therefore:

Authentication and profile completion should be treated as two separate concepts.

The flow becomes:

             OAuth Authentication
                      │
                      ↓
              User authenticated
                      │
                      ↓
              Is profile complete?
                 /           \
               Yes            No
                │              │
                ↓              ↓
           Dashboard      Complete Profile
                               │
                               ↓
                           Dashboard

This allows the user to authenticate immediately while still requiring application-specific information later.

Another Problem: Password Authentication After OAuth

Consider another situation.

A user initially creates an account using Google:

Google OAuth
     ↓
User created

The user never created a password.

The database may therefore contain:

User
────────────────────────
email: user@example.com
password: NULL

If the user later tries Email + Password, there is no password credential to verify.

Therefore, the application needs a Set Password / Add Password flow.

For example:

Google Account
      │
      ↓
Existing User
      │
      ↓
Set Password
      │
      ↓
Password Authentication Enabled

After this, the same user can authenticate through multiple methods.

The Solution: One User, Multiple Identities

The main architectural change is:

A user account should not be tied to a single authentication provider.

Instead:

                         ┌──────────────┐
                         │     USER     │
                         │   usr_123    │
                         └──────┬───────┘
                                │
              ┌─────────────────┼─────────────────┐
              │                 │                 │
              ↓                 ↓                 ↓
        ┌───────────┐     ┌───────────┐     ┌───────────┐
        │  Google   │     │  GitHub   │     │ Password  │
        │ Identity  │     │ Identity  │     │ Credential│
        └───────────┘     └───────────┘     └───────────┘

The User represents the actual application account.

The linked identities represent the ways that user can authenticate.

Recommended Database Model

Instead of storing everything directly inside the User record, use a separate Account or Identity table.

For example:

┌──────────────────────────────┐
│             User             │
├──────────────────────────────┤
│ id                           │
│ email                        │
│ name                         │
│ avatar                       │
│ profileCompleted             │
│ createdAt                    │
│ updatedAt                    │
└──────────────┬───────────────┘
               │
               │ 1 : N
               ↓
┌──────────────────────────────┐
│           Account            │
├──────────────────────────────┤
│ id                           │
│ userId                       │
│ provider                     │
│ providerAccountId            │
│ createdAt                    │
│ updatedAt                    │
└──────────────────────────────┘

The relationship is:

User 1 ─────────── N Accounts

Example Database Records

Suppose a user initially registers with Google.

User

┌──────────────────────────────┐
│ User                         │
├──────────────────────────────┤
│ id:    usr_123               │
│ email: user@example.com      │
│ name:  John Doe              │
└──────────────────────────────┘

Google Account

┌──────────────────────────────┐
│ Account                      │
├──────────────────────────────┤
│ userId:            usr_123   │
│ provider:          GOOGLE    │
│ providerAccountId: google_1  │
└──────────────────────────────┘

Later, the same user authenticates with GitHub:

┌──────────────────────────────┐
│ Account                      │
├──────────────────────────────┤
│ userId:            usr_123   │
│ provider:          GITHUB    │
│ providerAccountId: github_1  │
└──────────────────────────────┘

Now the database represents:

                    User #123
                       │
              ┌────────┴────────┐
              │                 │
              ↓                 ↓
           Google             GitHub
          Account             Account

Both identities point to userId = usr_123.

Therefore, they represent the same application user.

My Initial Idea

Initially, I thought about storing the authentication providers directly inside the user object:

{
  authProvider: {
    google: {
      id: "google-account-id"
    },
    github: {
      id: "github-account-id"
    },
    custom: {
      id: "email"
    }
  }
}

Conceptually, this represents what I wanted:

                 User
                  │
       ┌──────────┼──────────┐
       ↓          ↓          ↓
    Google      GitHub     Custom

However, for a relational database, I found that a separate Account/Identity table is a better representation.

It allows the relationship to naturally become:

User 1 ──────────── N Accounts

instead of continuously adding authentication providers to the user record.

It also makes it easier to:

• Add new providers

• Enforce unique provider identities

• Query linked accounts

• Unlink providers

• Manage provider-specific identifiers

• Maintain a clean database structure

The Unified Authentication Flow

The complete flow can be represented as:

                    ┌─────────────────────┐
                    │ Authentication      │
                    │ Request             │
                    └──────────┬──────────┘
                               │
             ┌─────────────────┼─────────────────┐
             ↓                 ↓                 ↓
        ┌─────────┐       ┌─────────┐       ┌─────────┐
        │Password │       │ Google  │       │ GitHub  │
        └────┬────┘       └────┬────┘       └────┬────┘
             │                 │                 │
             └─────────────────┼─────────────────┘
                               ↓
                    ┌─────────────────────┐
                    │ Authenticate        │
                    │ Identity            │
                    └──────────┬──────────┘
                               ↓
                    ┌─────────────────────┐
                    │ Find linked Account │
                    └──────────┬──────────┘
                               │
                     ┌─────────┴─────────┐
                     ↓                   ↓
                   Found              Not Found
                     │                   │
                     ↓                   ↓
                Get User          Create or securely
                                  link Account
                     │                   │
                     └─────────┬─────────┘
                               ↓
                         ┌───────────┐
                         │   User    │
                         └─────┬─────┘
                               ↓
                    ┌─────────────────────┐
                    │ Profile Complete?   │
                    └──────────┬──────────┘
                               │
                      ┌────────┴────────┐
                      ↓                 ↓
                    Yes                No
                      │                 │
                      ↓                 ↓
                 Dashboard        Profile Setup

Example: Google → GitHub

Let's walk through the original problem using the new architecture.

First Login — Google

User
 ↓
Google OAuth
 ↓
Google verifies identity
 ↓
No Google Account exists
 ↓
Create User
 ↓
Create Google Account
 ↓
Create Session

Database:

User #123
   │
   └── Google Account

Second Login — GitHub

The same user chooses GitHub:

User
 ↓
GitHub OAuth
 ↓
GitHub verifies identity
 ↓
No GitHub Account exists
 ↓
Check account-linking rules
 ↓
Link GitHub Account to User #123

Database:

User #123
   │
   ├── Google Account
   │
   └── GitHub Account

No second user needs to be created.

Adding Password Authentication

The user can later explicitly create a password for the existing account.

User #123
   │
   ├── Google Account
   ├── GitHub Account
   └── Password Credential

Now all three authentication methods eventually resolve to User #123.

Account Linking Requires Security

One important lesson is that we should not blindly merge accounts simply because two providers return the same email address.

A safer flow is:

OAuth Authentication
        │
        ↓
Verify Provider Identity
        │
        ↓
Existing Linked Identity?
       / \
     Yes  No
      │    │
      │    ↓
      │  Existing User?
      │    / \
      │  No   Yes
      │   │     │
      │   ↓     ↓
      │ Create  Secure
      │ User    Linking Flow
      │   │     │
      └───┴─────┘
            ↓
           User

The exact linking policy depends on the application.

The system should also consider:

• Verified provider email

• OAuth state

• CSRF protection where applicable

• Secure cookies

• Session expiration

• Session revocation

• Password hashing

• Rate limiting

• Provider account IDs

• Explicit account-linking flows

This prevents an external identity from being incorrectly linked to the wrong application account.

Authentication, Identity, and Session Are Different

One of the biggest architectural lessons from this problem was that these concepts should not be treated as the same thing.

┌──────────────────────┐
│         User         │
│                      │
│ Application Account  │
└──────────┬───────────┘
           │
           │ has
           ↓
┌──────────────────────┐
│ Identity / Account   │
│                      │
│ How the user         │
│ authenticates        │
└──────────┬───────────┘
           │
           │ creates
           ↓
┌──────────────────────┐
│       Session        │
│                      │
│ Current authenticated│
│ access               │
└──────────────────────┘

For example:

                    User #123
                        │
           ┌────────────┼────────────┐
           ↓            ↓            ↓
        Google        GitHub       Password
        Identity      Identity     Credential
           │            │            │
           └────────────┼────────────┘
                        ↓
                     Session
                        ↓
                 Authenticated App

The session ultimately belongs to the application user, not to Google or GitHub.

Final Architecture

The final architecture I moved toward looks like this:

                         ┌──────────────┐
                         │     USER     │
                         │   usr_123    │
                         └──────┬───────┘
                                │
                    ┌───────────┼───────────┐
                    │           │           │
                    ↓           ↓           ↓
              ┌──────────┐ ┌─────────┐ ┌──────────┐
              │  Google  │ │ GitHub  │ │ Password │
              │ Identity │ │Identity │ │Credential│
              └──────────┘ └─────────┘ └──────────┘
                    │           │           │
                    └───────────┼───────────┘
                                ↓
                         ┌──────────────┐
                         │   SESSION    │
                         └──────┬───────┘
                                ↓
                       Authenticated User
                                │
                       ┌────────┴────────┐
                       ↓                 ↓
                 Profile Complete    Profile Missing
                       │                 │
                       ↓                 ↓
                   Dashboard        Onboarding

The Main Lesson

The most important lesson I learned from this implementation is:

Authentication providers should identify a user, not define the user.

A single application user can have multiple authentication identities:

                    ONE USER
                       │
          ┌────────────┼────────────┐
          ↓            ↓            ↓
       Google        GitHub       Password
          │            │            │
          └────────────┼────────────┘
                       ↓
                    Session
                       ↓
                Application

Once this distinction is made, several problems become much easier to reason about:

• Multiple OAuth providers

• Custom email/password authentication

• Account linking

• Duplicate account prevention

• Profile completion

• Password setup after OAuth

• Session management

• Provider-specific identities

The key is to model User, Identity/Credential, and Session as separate concepts instead of treating every authentication method as a separate user account.

Let’s consider a simple example of finding the heaviest ball in a basket. We’ll compare two approaches to understand how longer code can sometimes be more efficient.

Case 1 – Simple and Short (Less Efficient) =>

#include <iostream>

using namespace std;

int main(){
 
   //To Find Max Weight

   int n = 9;
   int basket[9] = {1,1,1,1,1,2,1,1,1};
   int maxWeight = 0;
   int position;

   for(int i = 0; i< n; i++){
      if(maxWeight < basket[i]){
        maxWeight = basket[i];
        position = i+1;
      }
   }

   cout << "Maximum Weight: " << maxWeight << " at position " << position;
    
}

In Case 1, we use a simple loop to find the maximum weight in the basket. While the code is short (about 10 lines), it always runs through all n elements—even if the maximum is at the beginning.

Case 2 – Slightly Longer (More Efficient in This Case) =>

#include <iostream>

using namespace std;

int main(){

int n = 9;
int basket[9] = {1,1,1,1,1,2,1,1,1};
int basketA = {basket[0] + basket[1] + basket[2]};
int basketB = {basket[3] + basket[4] + basket[5]};
int basketC = {basket[6] + basket[7] + basket[8]};
int maxWeight = 0;
int position;

if(basketA > basketB){
    for(int i = 0; i < 3; i++){
        if (maxWeight < basket[i])
        {
            maxWeight = basket[i];
            position = i+1;
        }
        
    }
}else if(basketB > basketC){
    for(int i = 3; i < 6; i++){
        if (maxWeight < basket[i])
        {
            maxWeight = basket[i];
            position = i+1;
        }
        
    }
}else{
    for(int i = 6; i < 9; i++){
        if (maxWeight < basket[i])
        {
            maxWeight = basket[i];
            position = i+1;
        }
        
    }
}
 
cout << "Maximum Weight: " << maxWeight << " at position " << position;
    
}

In Case 2, we divide the basket into three equal parts and compare the total weights of each part. Then, we only check the part that has the highest total weight, reducing the number of comparisons. This increases the number of lines but improves efficiency in this specific scenario, where we already know the max is likely in a heavier group.

Conclusion

Shorter code might seem appealing at first glance, but efficiency isn't just about line count—it's about context, logic, and intent. In real-world scenarios, a few extra lines can significantly improve performance or adaptability. Case 2 demonstrates how a longer solution can be more optimized by reducing unnecessary work. Ultimately, the best code isn't always the shortest—it's the one that balances clarity, efficiency, and problem-solving effectively.