DEV Community: Divyanshi Narang

Authorization vs Authentication

Divyanshi Narang — Mon, 07 Sep 2026 13:43:00 +0000

Authentication (AuthN)

It verifies the identity of the user.

Who are you? → Verify identity → Establish authenticated user

Examples:

Login with email/password
OTP verification
Google login
Session/JWT used to maintain the authenticated state

Authorization (AuthZ)

It determines the user's permissions and access rights.

What are you allowed to do? → Check permissions/access → Allow or deny action

Examples:

Roles — Admin, Manager, User
Permissions — delete_user, approve_leave
Resource ownership — user can edit their own profile
Policies/attributes — e.g. a manager can approve requests only for their team

Can you have authorization without authentication?

Yes.

For public resources, authentication isn't required because the access policy allows everyone to access them.

GET /products → Public → No authentication required → Access allowed

For protected resources:

GET /profile → Authentication required → Identify user → Check authorization → Allow/Deny

So, authentication is not always required for authorization, but it is generally required when authorization depends on the user's identity, role, or permissions.

TLDR ;)

“Authentication verifies the identity of user, while authorization determines what that authenticated user is allowed to access or perform a particular action.”

CP vs AP

Divyanshi Narang — Sun, 06 Sep 2026 16:31:41 +0000

As we discussed,

In distributed systems, CAP theorem is not simply about choosing any two out of three. It describes the trade-off between Consistency and Availability when a network Partition occurs.

When the network itself has failed, we can't always guarantee both simultaneously.

What about CA?

CA means Consistency + Availability, without Partition Tolerance.

That means the system provides:

Consistency: Every request sees a consistent/current view of the data.
Availability: Every request receives a response.
No Partition Tolerance: The system does not account for network partitions between nodes.

But in a real distributed system, network partitions can happen. So Partition Tolerance is generally something we need to account for, making the practical trade-off between CP and AP during a partition.

This leads us to two common approaches in distributed systems.

CP — Consistency + Partition Tolerance

A CP system prioritizes consistency when a partition occurs.

During a partition, if the system cannot guarantee that the data is consistent, it may reject or delay the request.

Network Partition
       ↓
Cannot guarantee consistent data
       ↓
Don't return potentially stale data
       ↓
Consistency preserved
Availability sacrificed

The priority is:

"I'd rather fail the request than return incorrect or stale data."

This can be useful for systems where incorrect information is worse than being temporarily unavailable.

Examples where strong consistency may be important:

Money transfers
Account balances
Payment authorization

AP — Availability + Partition Tolerance

An AP system prioritizes availability when a partition occurs.

It continues responding even if some nodes might temporarily have different versions of the data.

Network Partition
       ↓
Nodes cannot communicate
       ↓
Still respond to requests
       ↓
Availability preserved
Consistency may temporarily suffer

The priority becomes:

"I'd rather give the user an answer and resolve the inconsistency later."

This can be useful when temporary inconsistency or stale data is acceptable.

Examples where temporary inconsistency may be acceptable:

Shopping carts
Product recommendations
Likes
View counts

Conclusion

As a developer, I don't think the important part is memorizing:

"CP for this database, AP for that database."

The more important part is understanding the trade-off.

Whenever we're designing a distributed system, we should ask:

What should happen when our servers cannot communicate with each other?

Should we:

Stop serving requests to protect correctness?
Or continue serving requests and potentially return stale data?

That decision can affect the architecture of the entire system.

CAP Theorem Finally Made Sense to Me

Divyanshi Narang — Sat, 05 Sep 2026 13:23:47 +0000

While studying system design, I came across something called CAP theorem.

At first, it sounded simple:

A distributed system can choose any two out of Consistency, Availability, and Partition Tolerance.

But the more I read about it, the more I realized that this explanation can be a little misleading.

So I tried to understand it through a simple real-world example: a single restaurant inventory with two branches.

What is CAP theorem?

CAP theorem describes fundamental trade-off that exists in distributed systems. It was introduced by Eric Brewer in 2000.

CAP stands for:

C - Consistency
A - Availability
P - Partition Tolerance

But before understanding the theorem, let's understand what these three terms actually mean.

Suppose you have a restaurant named PizzaPazi having two branches and sharing a single inventory.

Consistency - A customer buys the last Pizza from Branch A. Branch A knows Pizza left = 0. For system to be consistent, Branch B should also reflect the latest state.

In simple terms:
All nodes should agree on the current state of the data.

Availability - Now imagine, Branch A is temporarily unavailable. Should Branch B also stop serving customers? -> Not necessarily. Branch B should continue responding to requests.

That's Availability:
The system continues responding to requests even when some parts of the system in unavailable.

Partition Tolerance - Due to some reasons, the network connecting A and B breaks. Both branches are running, but they cannot communicate. This is a network partition.

Partition Tolerance means:
The distributed system continues operating despite nodes being unable to communicate with each other.

Where does the CAP problem come in?

Suppose Branch A sells the last Pizza while the network is down.

Branch A -> 0 available
Branch B -> 1 available

A customer now asks Branch B for the Pizza.

Branch B has a choice:

Stop and wait for Branch A → preserve the latest consistent state.
Continue serving the customer → remain available, but potentially use stale data.

And that's the core idea of CAP:
** When a network partition occurs, you cannot guarantee both Consistency, and Availability at the same time.**

The biggest thing I learned is that CAP isn't just about memorizing three words.

It's about asking:
What should my system do when two parts of it can no longer communicate?

TLDR ;)

CAP theorem states that in a distributed system, when a network partition occurs between nodes, we cannot guarantee both strong Consistency and Availability at the same time.

Consistency means every request gets the latest, correct data.
Availability means every request receives a response.
Partition Tolerance means the system continues operating even when nodes cannot communicate with each other.

Since network partitions are inevitable in distributed systems, the practical trade-off is usually between Consistency and Availability during a partition — resulting in CP or AP systems.

Resources I used

While learning this topic, these were particularly useful:

A Plain English Introduction to CAP Theorem — Kaushik Sathupadi

Hello Interview's video explanation

Understanding the CAP Theorem — Neha

Divyanshi Narang

Sep 6

CP vs AP

#architecture #backend #computerscience #systemdesign

2 min read