DEV Community: Nishant Gaurav

Every API in This Series Was Built for Speed. SOAP Was Built for Trust.

Nishant Gaurav — Sat, 19 Sep 2026 13:30:00 +0000

REST is flexible. GraphQL is precise. gRPC is fast. WebSockets are persistent. Webhooks are reactive. Every API type you've learned in this series optimises for developer convenience or performance.

SOAP optimises for something different: airtight security, strict contracts, and zero ambiguity. That's why it was built in 1998, why most developers think it's dead, and why banks and insurance companies still run billions of transactions through it every single day.

Why SOAP Still Exists

When you transfer money between banks, send an insurance claim, or file a government tax return through software, the stakes of a malformed or tampered message are severe. A missing field isn't a bug to fix in the next deploy. It's a financial error with legal consequences.

REST doesn't enforce message structure. You can send whatever JSON you want and the server has to validate it manually. SOAP enforces structure at the protocol level. If the message doesn't match the defined schema exactly, it is rejected before it ever reaches application code.

That strictness is not a limitation. For industries where every message must be verifiable, auditable, and tamper-proof, it's the entire point.

What a SOAP Message Looks Like

Every SOAP message is XML wrapped in a strict four-part envelope. There are no exceptions to this structure.

<!-- Every SOAP message follows this exact envelope structure, no exceptions -->
<soap:Envelope
  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

  <soap:Header>
    <!-- Authentication and security tokens live here -->
    <wsse:Security>
      <wsse:UsernameToken>
        <wsse:Username>bankuser</wsse:Username>
        <wsse:Password>hashedpassword</wsse:Password>
      </wsse:UsernameToken>
    </wsse:Security>
  </soap:Header>

  <soap:Body>
    <!-- The actual request payload -->
    <GetAccountBalance>
      <AccountId>ACC123456</AccountId>
      <Currency>INR</Currency>
    </GetAccountBalance>
  </soap:Body>

</soap:Envelope>

Where REST lets you structure your JSON however you want, SOAP's XML schema is defined in advance in a WSDL file (Web Services Description Language). The WSDL is a machine-readable contract that describes every operation the service supports, every field each message must contain, and every data type each field must be. Both sides must conform to it exactly.

The Security Layer That Sets SOAP Apart

Every other API type in this series relies on HTTPS for transport security. SOAP goes further with WS-Security, a standard that operates at the message level rather than the transport level.

This distinction matters in regulated industries. HTTPS secures the connection between two points. If there is a proxy, a load balancer, or any intermediary in the chain, the message is decrypted and re-encrypted at each hop. WS-Security encrypts the message body itself, so it stays protected end-to-end regardless of how many systems it passes through.

SOAP vs REST: The Real Trade-off

When to Use SOAP, When Not To

Use SOAP when you are integrating with a banking API, a government tax system, a healthcare records platform, or any legacy enterprise system that exposes a SOAP endpoint. You will rarely choose SOAP for a new greenfield project, but in regulated industries, the compliance requirements often mandate it.

Skip SOAP when you control both sides of the integration and have no legacy or compliance constraints. The verbosity of XML, the complexity of WSDL files, and the lack of caching support make SOAP slower to build and harder to debug than REST for modern applications.

What You Now Understand

SOAP is not a relic that survived by accident. It survived because the industries that adopted it have requirements that REST genuinely cannot meet: message-level encryption, digital signatures embedded in every payload, and machine-enforced schemas with no room for variation.

You've now completed the full API picture. REST for standard web communication. GraphQL for flexible data fetching. WebSockets for real-time two-way connections. Webhooks for event-driven server notifications. gRPC for high-speed internal service communication. SOAP for strict, secure, enterprise-grade integration.

Every tool exists because a specific problem made the previous tools insufficient. That's the pattern worth carrying forward.

Count Subsets With a Given Difference: Two Equations, One DP Problem

Nishant Gaurav — Sat, 19 Sep 2026 10:28:48 +0000

Chapter 5 reduced a two-subset problem to a one-number search using algebra. This chapter does the same thing, but this time the algebra hands you a direct answer instead of a search range.

The last chapter asked: which subset sum S1 minimises |R - 2S1|? This chapter asks: given that S1 - S2 = D, how many ways can that partition happen?

Different question. Same two equations. Same Count Subset Sum DP you already know.

The Problem

Given an array and a difference D, count the number of ways to divide the array into two subsets S1 and S2 such that S1 - S2 = D.

arr = [1, 1, 2, 3]
D = 1

Find all partitions where the difference between subset sums is exactly 1.

The Algebra (Again)

You've seen this setup before. Every element goes into either S1 or S2, so:

S1 + S2 = R     (R = total sum)
S1 - S2 = D     (given)

Add both equations:

S1 + S2 = R
S1 - S2 = D
───────────────
2S1     = R + D

S1 = (R + D) / 2

You don't need to find both subsets. Find one subset whose sum equals (R + D) / 2. Count how many such subsets exist. That count is your answer.

Count Subsets With Given Difference just became Count Subset Sum.

Two Checks Before You Touch the DP

Both of these need to pass before computing S1 = (R + D) / 2.

Check 1: |D| <= R

The maximum difference between two subsets is the total sum itself (one subset gets everything, the other gets nothing). If D exceeds R, the partition is impossible.

if abs(diff) > total:
    return 0

Check 2: (R + D) must be even

S1 = (R + D) / 2 must be an integer because subset sums are always integers. If R + D is odd, no valid partition exists.

if (total + diff) % 2 != 0:
    return 0

The DP: Count Subset Sum (Returning Again)

The transition is identical to Chapter 4. Store the count of subsets, combine with +, initialise only T[0][0] = 1, and loop j from 0 not 1.

class Solution:

    def subsetSum(self, arr, subset):

        n = len(arr)

        # T[i][j] = number of subsets using first i elements
        # whose sum is exactly j
        T = [[0] * (subset + 1) for _ in range(n + 1)]

        # Only base case: one way to make sum 0
        # with zero elements — the empty subset
        T[0][0] = 1

        for i in range(1, n + 1):

            # Start from 0 — zeros must flow through
            # the transition naturally
            for j in range(subset + 1):

                if arr[i - 1] <= j:
                    # Count ways from both choices
                    T[i][j] = (
                        T[i - 1][j - arr[i - 1]]  # include
                        +
                        T[i - 1][j]                # exclude
                    )
                else:
                    # Element too large — must exclude
                    T[i][j] = T[i - 1][j]

        return T[n][subset]


    def countPartitions(self, arr, diff):

        total = sum(arr)

        # Partition is impossible if difference exceeds total
        if abs(diff) > total:
            return 0

        # S1 = (R+D)/2 must be an integer
        if (total + diff) % 2 != 0:
            return 0

        # Directly calculated — no searching needed
        subset = (total + diff) // 2

        return self.subsetSum(arr, subset)

Target Sum: The Same Problem in Disguise

LeetCode's Target Sum problem asks something that looks completely different: given an array of numbers, assign a + or - sign to every element. Count the ways to reach a specific target.

nums = [1, 1, 2, 3]
target = 1

+1 -1 -2 +3 = 1  ✓
+1 +1 +2 -3 = 1  ✓
...

It feels like a sign-assignment problem. It isn't. It's two subsets in disguise.

Every element with a + sign belongs to S1. Every element with a - sign belongs to S2. The final expression S1 - S2 must equal target. That gives you:

S1 - S2 = target
S1 + S2 = total

→ S1 = (total + target) / 2

Count the subsets with sum S1. You're done.

Target Sum Code

The logic is identical to Count Partitions. Only the variable names change.

class Solution:

    def subsetSum(self, nums, subset):

        n = len(nums)

        # T[i][j] = number of subsets using first i elements
        # whose sum is exactly j
        T = [[0] * (subset + 1) for _ in range(n + 1)]

        # One way to make sum 0: empty subset
        T[0][0] = 1

        for i in range(1, n + 1):

            # Start from 0 for correct zero handling
            for j in range(subset + 1):

                if nums[i - 1] <= j:
                    # Count both choices
                    T[i][j] = (
                        T[i - 1][j - nums[i - 1]]  # include
                        +
                        T[i - 1][j]                 # exclude
                    )
                else:
                    T[i][j] = T[i - 1][j]

        return T[n][subset]


    def findTargetSumWays(self, nums, target):

        total = sum(nums)

        # target cannot exceed the total range
        if abs(target) > total:
            return 0

        # S1 = (total + target)/2 must be an integer
        if (total + target) % 2 != 0:
            return 0

        # Same conversion as Count Partitions
        subset = (total + target) // 2

        return self.subsetSum(nums, subset)

Why These Two Problems Are Identical

Look at them side by side.

	Count Partitions	Target Sum
Equation	`S1 - S2 = D`	`S1 - S2 = target`
Total	`S1 + S2 = R`	`S1 + S2 = R`
S1	`(R + D) / 2`	`(R + target) / 2`
Check 1	`\	D\
Check 2	{% raw %}`(R + D)` even	`(R + target)` even
DP used	Count Subset Sum	Count Subset Sum

The difference is semantic, not structural. One problem uses the word "difference," the other uses "target." The algebra is identical. The DP is identical.

The Full Knapsack Pattern Chain

Quick Revision

Count Partitions With Given Difference

S1 - S2 = D
S1 + S2 = R
→ S1 = (R + D) / 2

Check 1: abs(D) <= R        → else return 0
Check 2: (R + D) % 2 == 0   → else return 0

subset = (R + D) // 2
return countSubsetSum(arr, subset)

Target Sum

+ elements = S1
- elements = S2
S1 - S2 = target
→ S1 = (R + target) / 2

Check 1: abs(target) <= R
Check 2: (R + target) % 2 == 0

subset = (R + target) // 2
return countSubsetSum(nums, subset)

Both reduce to Count Subset Sum with T[0][0] = 1 and loop starting from j = 0.

What You Now Understand

Six problems deep. The Knapsack chain is now complete for the 0/1 pattern. Every problem reused either Subset Sum or Count Subset Sum with one mathematical step in front of it. The algebra was the same twice: two equations, one variable, one direct target.

The pattern to carry forward is simple. When you see two subsets and a given difference, write S1 - S2 = D and S1 + S2 = R, add them, and you'll have the subset sum you need to count. The two checks (|D| <= R and (R + D) is even) guard against edge cases before the DP even starts.

The next part of the series moves into Unbounded Knapsack, where the structure shifts: instead of each item being available at most once, an item can be chosen as many times as needed. The choice diagram changes. The table direction changes. The core thinking stays exactly the same.

Minimum Subset Sum Difference & Target Sum

Nishant Gaurav — Fri, 18 Sep 2026 11:30:00 +0000

Every chapter in this series has followed the same move: take the Knapsack structure, ask a different question, change one operation. Chapter 3 changed max() to or. Chapter 4 changed or to +. This chapter doesn't change the operation at all.

Instead, it adds a layer of mathematics on top of Subset Sum that reduces a problem about two subsets into a problem about one number on a number line.

Once the math clicks, the code is almost nothing new. You've already written it.

The Problem

Divide an array into two subsets S1 and S2 such that the absolute difference between their sums is as small as possible.

arr = [1, 6, 11, 5]

One possible partition:
  S1 = [6, 5]  → sum = 11
  S2 = [1, 11] → sum = 12

  |11 - 12| = 1

The answer for this array is 1.

The Mathematics That Unlocks the Problem

Before touching any DP, work out the algebra.

Every element goes into either S1 or S2. So:

S1 + S2 = R     (R = total sum of the array)

You want to minimise |S1 - S2|. Substitute S2 = R - S1:

|S1 - S2|
= |S1 - (R - S1)|
= |2S1 - R|
= |R - 2S1|

The problem is now: find a possible subset sum S1 that minimises |R - 2S1|.

You don't need to explicitly construct either subset. You don't need to know which elements go where. You just need to know which values S1 can take. And that is exactly what Subset Sum answers.

The Number Line Intuition

Look at |R - 2S1|. As S1 increases from 0 toward R, the expression 2S1 moves from 0 toward 2R. The difference |R - 2S1| is smallest when S1 is closest to R/2.

0 ─────────────── R/2 ─────────────── R
                   ↑
              Ideal S1
         (difference = 0 here)

The further S1 moves from the centre, the larger the difference grows. So the problem reduces to: among all possible subset sums, find the one closest to R/2.

Why You Only Check Half the Number Line

This is the part that confused earlier, so it gets its own section.

Suppose R = 22 and S1 = 8 is a possible subset sum. Then S2 = 14. The difference is |8 - 14| = 6.

Now flip the perspective. If instead you call the 14-element group S1, you get S1 = 14 and S2 = 8. The difference is still |14 - 8| = 6.

Every subset sum above R/2 is the mirror of a subset sum below R/2. They produce identical differences. Checking both is redundant.

So: run Subset Sum only up to target = R // 2. This is a search-space limit, not a claim that the answer must have a subset summing to exactly R/2.

target = R // 2

This means: "calculate possible sums from 0 to R//2 only."
It does NOT mean: "the answer must be R//2."

If no subset sums to exactly R//2, that's fine.
You want the closest possible value.

The Connection to Subset Sum

The complete reduction:

The Code

The Subset Sum function returns the entire last row of the DP table — every possible subset sum up to target — rather than a single boolean. The minimum difference function uses that row to find the best S1.

class Solution:

    def subsetSum(self, arr, target):

        n = len(arr)

        # T[i][j] = True if sum j is achievable
        # using first i elements
        T = [[False] * (target + 1) for _ in range(n + 1)]

        # Sum 0 is always possible — empty subset
        for i in range(n + 1):
            T[i][0] = True

        for i in range(1, n + 1):
            for j in range(1, target + 1):

                if arr[i - 1] <= j:
                    # Include OR exclude current element
                    T[i][j] = (
                        T[i - 1][j - arr[i - 1]]
                        or
                        T[i - 1][j]
                    )
                else:
                    # Can't include — must exclude
                    T[i][j] = T[i - 1][j]

        # Return the last row — all possible sums for n elements
        # up to target
        return T[n]


    def minDifference(self, arr):

        # Total sum R
        R = sum(arr)

        # Only need subset sums up to R//2
        # (mirror symmetry makes the other half redundant)
        target = R // 2

        # Get all possible subset sums from 0 to target
        possible = self.subsetSum(arr, target)

        minimum = float('inf')

        # Check every possible S1 from 0 to R//2
        for S1 in range(target + 1):

            if possible[S1]:
                # S2 = R - S1
                # |S1 - S2| = |R - 2*S1|
                diff = abs(R - 2 * S1)
                minimum = min(minimum, diff)

        return minimum

Walking Through the Example

arr = [1, 6, 11, 5]

R = 1 + 6 + 11 + 5 = 23

target = 23 // 2 = 11

After running Subset Sum up to 11, the possible row looks like:

sum:      0   1   2   3   4   5   6   7   8   9   10  11
possible: T   T   F   F   F   T   T   T   F   F   F   T

Now check each possible S1:

S1 = 0  → |23 - 0|  = 23
S1 = 1  → |23 - 2|  = 21
S1 = 5  → |23 - 10| = 13
S1 = 6  → |23 - 12| = 11
S1 = 7  → |23 - 14| = 9
S1 = 11 → |23 - 22| = 1   ← minimum

Answer: 1.

The subset summing to 11 is [11]. The remaining elements [1, 6, 5] sum to 12. Difference is 1.

The One Mistake to Avoid

target = R // 2 is easy to misread. Here is what it does and does not mean:

target = R // 2

DOES mean: "only calculate subset sums from 0 to R//2."
           This is a search-space optimisation.

DOES NOT mean: "there must exist a subset whose sum is R//2."
               There might be no such subset — that's fine.
               You're looking for the closest possible value.

If R = 23 and no subset sums to 11, you simply check all the sums that do exist (say 10 and 7) and return the minimum difference among those. The // is integer division because subset sums are always integers. R/2 = 11.5 is unreachable so 11 is the highest integer worth checking.

The Full Chain So Far

Quick Revision

The core math

S1 + S2 = R
|S1 - S2| = |R - 2S1|
Goal: find S1 that minimises |R - 2S1|

The DP strategy

Run Subset Sum up to target = R // 2
Get all possible S1 values
For each possible S1: compute |R - 2S1|
Return the minimum

The target clarification

target = R // 2 is a search-space limit
It is NOT the required subset sum
The closest achievable S1 to R/2 is the answer

When to recognise this pattern

"Divide into two subsets, minimise difference"
        ↓
S1 + S2 = R
        ↓
|R - 2S1|
        ↓
Subset Sum DP

What You Now Understand

Five problems into the Knapsack chain. Each one reused the structure from the previous chapter and added one idea: a different operation, a mathematical trick, or a search-space insight. Minimum Subset Sum Difference added the algebra that collapses a two-subset problem into a one-number search.

Chapter 6 continues with Target Sum, where the question changes again: instead of minimising a difference, you assign + or - signs to elements and count the ways to reach a specific target. The Subset Sum table returns, and a new mathematical reduction makes it possible.

The pattern keeps building. The new code keeps shrinking.

Count of Subsets: One Word Changed. Everything Followed.

Nishant Gaurav — Thu, 17 Sep 2026 12:30:00 +0000

Chapter 3 ended with a hint. The shift from Knapsack to Subset Sum was a one-word change: max() became or. The structure stayed identical. Only the question changed.

This chapter makes the next one-word change. Subset Sum asks "is it possible?" Count of Subsets asks "how many ways?" The answer shifts from a boolean to an integer. The DP table changes what it stores. And or becomes +.

That's the entire difference. Everything else is the same pattern you've already seen twice.

The Problem

Given an array and a target sum, count the number of subsets whose elements add up to exactly that target.

arr = [2, 3, 5]
sum = 5

Subsets that make 5:
  [5]       → 5
  [2, 3]    → 2 + 3 = 5

Answer = 2

Subset Sum would have returned True here. Count of Subsets returns 2. Same array. Same target. Different question.

The One Change That Separates These Two Problems

The choice diagram is identical. For every element, you include it or exclude it.

What changes is only the combining step:

Problem	Question	Combine with
0/1 Knapsack	Maximum value?	`max()`
Subset Sum	Is it possible?	`or`
Count of Subsets	How many ways?	`+`

The same choice diagram. Three different questions. Three different one-word operations.

The DP State

T[i][j] = number of subsets using the first i elements
           whose sum is exactly j

T[3][5] means: using only the first three elements, how many different subsets add up to 5?

The final answer sits at T[n][sum].

Initialisation: Where This Problem Gets Subtle

Here's where Count of Subsets needs more care than its predecessors.

T[0][0] represents zero elements and required sum zero. Exactly one subset achieves this: the empty subset {}. So:

T[0][0] = 1

For positive sums with zero elements, no subset is possible:

T[0][1...sum] = 0   # handled automatically by initialising the table to zero

The trap: In previous chapters, the base case was:

for i in range(n + 1):
    T[i][0] = True   # Subset Sum

Don't carry this into Count of Subsets. Do not write:

for i in range(n + 1):
    T[i][0] = 1   # WRONG for arrays that contain zeros

Only initialise T[0][0] = 1 and let the normal transition fill the rest. Here is why.

The Zero Problem

When the array contains zeros, the initialisation above produces wrong answers.

arr = [0]
sum = 0

Subsets with sum 0:
  {}    → empty subset
  {0}   → includes the zero element

Answer = 2, not 1

arr = [0, 0]
sum = 0

Subsets with sum 0:
  {}
  {first 0}
  {second 0}
  {first 0, second 0}

Answer = 4

Every zero doubles the count. Because a zero element has two valid choices, include it (sum unchanged) or exclude it (sum unchanged), and both choices are valid.

The Transition

If arr[i-1] <= j:
    T[i][j] = T[i-1][j-arr[i-1]] + T[i-1][j]
                      ↑                  ↑
                  include             exclude

If arr[i-1] > j:
    T[i][j] = T[i-1][j]

The Bottom-Up Solution

class Solution:

    def perfectSum(self, arr, target):

        n = len(arr)

        # T[i][j] = number of subsets from first i elements
        # whose sum equals j
        T = [[0] * (target + 1) for _ in range(n + 1)]

        # Only base case: empty subset makes sum 0 in exactly one way
        T[0][0] = 1

        for i in range(1, n + 1):

            # Loop from 0 — zero elements must flow through
            # the transition naturally, not be hard-coded
            for j in range(target + 1):

                if arr[i - 1] <= j:
                    # Count all ways from both choices
                    T[i][j] = (
                        T[i - 1][j - arr[i - 1]]  # include
                        +
                        T[i - 1][j]                # exclude
                    )
                else:
                    # Element too large — must exclude
                    T[i][j] = T[i - 1][j]

        return T[n][target]

Notice j starts from 0 in the inner loop, not from 1. In Subset Sum it started from 1 because T[i][0] = True was already set. Here it starts from 0 so zero-valued elements get processed through the transition correctly.

The Memoization Version

The same placeholder issue from Chapter 3 returns, with a new twist. You cannot use 0 as the "not yet computed" marker because 0 is a valid count.

None → state not yet calculated
0    → calculated, no valid subsets exist
1+   → calculated, this many valid subsets exist

class Solution:

    def perfectSum(self, arr, target):

        n = len(arr)

        # None = not yet calculated
        # 0 is a valid answer, so cannot use 0 as placeholder
        T = [[None] * (target + 1) for _ in range(n + 1)]

        def solve(n, k):

            # Base cases
            if n == 0 and k == 0:
                return 1   # empty subset is one valid way
            if n == 0:
                return 0   # no elements left, positive sum impossible

            # Return stored answer if already calculated
            if T[n][k] is not None:
                return T[n][k]

            if arr[n - 1] <= k:
                # Count ways from both choices
                T[n][k] = (
                    solve(n - 1, k - arr[n - 1])  # include
                    +
                    solve(n - 1, k)                # exclude
                )
            else:
                T[n][k] = solve(n - 1, k)         # must exclude

            return T[n][k]

        return solve(n, target)

The Mental Model You Should Carry Forward

This is the most important thing in this chapter. Not the code. Not the zero catch. This mental model.

Every time you see an include/exclude problem, ask one question first: what is the problem storing? The answer tells you the operation.

Maximum value → max()
Possibility → or
Count → +

You don't memorise three formulas. You memorise one structure and three questions.

Quick Revision

DP State

T[i][j] = number of subsets using first i elements with sum j

Initialisation

T[0][0] = 1    # only this — let zeros flow through the transition

Transition

# If current element fits:
T[i][j] = T[i-1][j-arr[i-1]] + T[i-1][j]

# If it doesn't fit:
T[i][j] = T[i-1][j]

The zero catch

arr = [0]       → 2 subsets with sum 0
arr = [0, 0]    → 4 subsets with sum 0
arr = [0, 0, 0] → 8 subsets with sum 0

Every zero doubles the count.
Don't hard-code T[i][0] = 1.

The memoization placeholder

None → not calculated
0    → calculated, zero ways

What You Now Understand

Four problems deep in the Knapsack pattern. The choices never changed. The structure never changed. What changed each time was a single operation: max(), or, +. Those three operations cover almost every variant of this pattern you'll encounter.

Chapter 5 continues with Minimum Subset Sum Difference, where the question shifts again: instead of finding a specific target, you want to minimise the gap between two subsets. The Subset Sum table you built here is exactly the tool that makes it possible.

Subset Sum and Equal Sum Partition: Same Pattern, Different Question

Nishant Gaurav — Wed, 16 Sep 2026 12:30:00 +0000

Chapter 2 ended with a promise: the 0/1 Knapsack pattern unlocks a chain of problems that all look different on the surface but share the same structure underneath. Subset Sum is the first link in that chain.

When you first read the Subset Sum problem, it doesn't look like Knapsack at all. There's no value array. There's nothing to maximise. It just asks: can you find a subset that adds up to a target?

But look at the choices. For every element, you either include it or you don't. That's the same fork from Knapsack. The only thing that changed is what you're storing in the table and how you combine the two choices. Once you see that, Subset Sum takes about five minutes to understand. And Equal Sum Partition takes about two minutes after that.

The Subset Sum Problem

Given an array of positive integers and a target sum, does any subset of the array add up to exactly that target?

arr = [3, 3, 4, 12, 5, 2]
sum = 9

Possible: 3 + 4 + 2 = 9 → True

arr = [3, 34, 4, 12, 5, 2]
sum = 30

No subset adds to 30 → False

The answer is a boolean, not a number. That single difference is what separates it from Knapsack.

How Subset Sum Connects to 0/1 Knapsack

The choice diagram is identical. For every element, you have two options:

The structural difference comes at the combining step.

In Knapsack, you take the max() of the two choices because you want the best possible value.

In Subset Sum, you use or because you're asking a yes/no question. If either choice can produce the target sum, the answer is True. You don't need both to work. You just need one.

Knapsack:    max(take, skip)     → find the maximum value
Subset Sum:  take OR skip        → find any path that works

That one-word change (max to or) is the entire difference between the two problems.

The DP State

The table is defined the same way as Knapsack, adapted for the new question.

T[i][j] = Can I make sum j using the first i elements?

T[3][5] means: using only the first three elements of the array, is there any subset that adds up to 5?

The final answer lives at T[n][sum].

Initialisation: The Base Cases

Sum = 0: An empty subset always makes sum zero. So every cell in column 0 is True.

No elements: If you have zero elements and need a positive sum, it's impossible. Every cell in row 0 (except T[0][0]) is False.

# Sum 0 is always achievable with an empty subset
for i in range(n + 1):
    T[i][0] = True

# No elements means no positive sum is possible
# T[0][0] stays True from the loop above
# T[0][1...sum] defaults to False from table initialisation

The Transition

For every cell T[i][j]:

If the current element fits (arr[i-1] <= j): check both choices. Include it (reduce the target by arr[i-1], look one row up) or exclude it (same target, look one row up). If either is True, this cell is True.

If the current element doesn't fit (arr[i-1] > j): only exclusion is possible. Copy the answer from the row above.

The Bottom-Up Solution

class Solution:

    def isSubsetSum(self, arr, target):

        n = len(arr)

        # T[i][j] = can we make sum j using first i elements?
        T = [[False] * (target + 1) for _ in range(n + 1)]

        # Base case: sum 0 is always possible
        for i in range(n + 1):
            T[i][0] = True

        for i in range(1, n + 1):
            for j in range(1, target + 1):

                if arr[i - 1] <= j:
                    # Include OR exclude the current element
                    T[i][j] = (
                        T[i - 1][j - arr[i - 1]]  # include
                        or
                        T[i - 1][j]                # exclude
                    )
                else:
                    # Element too large — must exclude
                    T[i][j] = T[i - 1][j]

        return T[n][target]

The Memoization Version

One important detail when writing the memoized version: you cannot use False as the "not yet calculated" placeholder. False is also a valid answer. The cache needs a third state that means "not computed yet."

Use None instead.

None  → state not yet calculated
True  → calculated, sum is possible
False → calculated, sum is not possible

class Solution:

    def isSubsetSum(self, arr, target):

        n = len(arr)

        # None = not calculated yet
        # Cannot use False — False is a valid answer
        T = [[None] * (target + 1) for _ in range(n + 1)]

        def solve(n, k):

            # Base cases
            if k == 0:
                return True
            if n == 0:
                return False

            # Return stored answer if already calculated
            if T[n][k] is not None:
                return T[n][k]

            if arr[n - 1] <= k:
                T[n][k] = (
                    solve(n - 1, k - arr[n - 1])  # include
                    or
                    solve(n - 1, k)                # exclude
                )
            else:
                T[n][k] = solve(n - 1, k)         # must exclude

            return T[n][k]

        return solve(n, target)

Equal Sum Partition: One Observation Away

The problem: divide an array into two subsets such that both have equal sums.

arr = [1, 5, 11, 5]

S1 = [1, 5, 5] → sum = 11
S2 = [11]       → sum = 11

True

At first glance this looks like a new problem. It isn't. Here's the key observation.

If the total sum of the array is R, and you want two equal subsets:

S1 + S2 = R
S1 = S2

→ S1 + S1 = R
→ 2 × S1  = R
→ S1      = R / 2

You don't need to find both subsets. Find one subset that sums to R/2. The remaining elements automatically form the second subset with the same sum.

Equal Sum Partition just became a Subset Sum problem.

The Odd Total Check

If the total sum is odd, equal partition is immediately impossible. You cannot split an integer array into two subsets each summing to a non-integer.

if total % 2 != 0:
    return False

Always check this first. It avoids running the entire DP on an input that can't possibly work.

The Equal Sum Partition Code

class Solution:

    def subsetSum(self, arr, target):

        n = len(arr)
        T = [[False] * (target + 1) for _ in range(n + 1)]

        # Base case: sum 0 always possible
        for i in range(n + 1):
            T[i][0] = True

        for i in range(1, n + 1):
            for j in range(1, target + 1):

                if arr[i - 1] <= j:
                    T[i][j] = (
                        T[i - 1][j - arr[i - 1]]
                        or
                        T[i - 1][j]
                    )
                else:
                    T[i][j] = T[i - 1][j]

        return T[n][target]


    def equalPartition(self, arr):

        total = sum(arr)

        # Odd total → equal partition is impossible
        if total % 2 != 0:
            return False

        # Find one subset that sums to half the total
        # The remaining elements form the second subset automatically
        target = total // 2

        return self.subsetSum(arr, target)

The Full Pattern So Far

Quick Revision

Subset Sum

T[i][j] = can I make sum j using first i elements?

If arr[i-1] <= j:
    T[i][j] = T[i-1][j-arr[i-1]] or T[i-1][j]

If arr[i-1] > j:
    T[i][j] = T[i-1][j]

Combine with OR, not max()
Use None (not False) as the memoization placeholder

Equal Sum Partition

total = sum(arr)

If total is odd → False

target = total // 2

Return SubsetSum(arr, target)

What You Now Understand

Two problems down in the Knapsack pattern chain. The structure stays the same: include or exclude, smaller subproblem, DP state, transition. What changes each time is the question being asked and the one-line operation that combines the two choices.

Knapsack asks for the maximum. Subset Sum asks for possibility. Equal Sum Partition asks for possibility after one mathematical reduction. The DP mechanics are nearly identical across all three.

Chapter 4 continues the chain with Count of Subsets: instead of asking "is it possible?", it asks "how many ways?" That shift from or to + is the next small change that opens the next set of problems.

0/1 Knapsack: The Pattern That Unlocks Half of All DP Problems

Nishant Gaurav — Tue, 15 Sep 2026 12:30:00 +0000

In Chapter 1, we built the DP mindset: recognise choices, find repeated subproblems, store answers instead of recomputing them. We didn't write a single DP table. We didn't touch a 2D array. We just learned how to think.

Chapter 2 is where that thinking meets its first real problem.

0/1 Knapsack is not just one problem. It's a pattern. Once you understand it deeply, a whole family of problems: Subset Sum, Equal Partition, Count of Subsets, Target Sum, Minimum Subset Difference — start looking like variations of the same idea. That's why we start here.

What Is the 0/1 Knapsack Problem?

You have a bag with a weight capacity W. You have n items, each with a weight and a value. You want to fill the bag to maximise total value without exceeding the capacity.

Weight:  [1, 3, 4, 5]
Value:   [1, 4, 5, 7]
Capacity W = 7

The critical constraint: each item can either be taken once or not taken at all. No fractions. No repeats. That's the 0/1 part.

0 → skip the item
1 → take the item

This is an optimisation problem (you want maximum value) where you have choices at every step (take or skip). Both conditions together are the first signal that DP is the right approach.

Step 1: Identify the Choices

Before writing any code, draw the choices.

At each item, you face exactly two options:

   Current Item
    /       \
 TAKE       SKIP

If you TAKE it:

You gain val[n-1] value
Your remaining capacity becomes W - wt[n-1]
You move to the next item: n-1

If you SKIP it:

You gain nothing
Capacity stays W
You still move to the next item: n-1

There's one constraint on the TAKE branch: you can only take the item if it actually fits. If wt[n-1] > W, the TAKE option disappears entirely and you can only skip.

Step 2: Identify the Base Case

Ask: what is the smallest valid input, and what does it return?

Two situations stop the recursion:

n == 0: no items left to consider
W == 0: no capacity remaining

In both cases, the maximum value you can achieve is zero.

if n == 0 or W == 0:
    return 0

Base case identified. Now write the recursion.

Step 3: Write the Recursive Solution

The base case and choice diagram translate directly into code. This is the whole point of drawing the choice diagram first.

def knapsack(wt, val, W, n):

    # Base Case — no items or no capacity
    if n == 0 or W == 0:
        return 0

    # Choice Diagram — item fits, so two choices exist
    if wt[n-1] <= W:
        return max(
            val[n-1] + knapsack(wt, val, W - wt[n-1], n-1),  # TAKE
            knapsack(wt, val, W, n-1)                          # SKIP
        )

    # Item doesn't fit — only one choice
    else:
        return knapsack(wt, val, W, n-1)                       # forced SKIP

The code is not something you memorised. It came directly from the choice diagram. That's the connection to hold onto.

Step 4: Find the Repeated States

The recursive solution works correctly but does redundant work. The same subproblem can appear multiple times across different branches of the recursion tree.

The state of any call is completely defined by two values: n and W. Everything else (the arrays wt and val) never changes. So if Knapsack(3, 5) appears twice in the recursion tree, both calls would return the exact same answer.

This repeated work is exactly what DP eliminates. Instead of recomputing Knapsack(2, 2) twice, compute it once, store the answer, and return it when the state appears again.

Step 5: Add Memoization (Top-Down DP)

Since the state is defined by (n, W), we need a matrix of size (n+1) × (W+1) to store every possible state.

Why n+1 and W+1? Because n ranges from 0 to n and W ranges from 0 to W. We need a slot for every value including zero.

T = [[-1] * (W + 1) for _ in range(n + 1)]

The -1 means "not yet computed." Once a state is computed, its answer replaces the -1.

The recursive code changes in exactly one place: before computing anything, check if the answer is already stored.

class Solution:

    def knapsack(self, W, val, wt):
        n = len(wt)
        T = [[-1] * (W + 1) for _ in range(n + 1)]

        def solve(n, W):

            # Base Case
            if n == 0 or W == 0:
                return 0

            # Already computed? Return stored answer
            if T[n][W] != -1:
                return T[n][W]

            # Choice Diagram
            if wt[n-1] <= W:
                T[n][W] = max(
                    val[n-1] + solve(n-1, W - wt[n-1]),   # TAKE
                    solve(n-1, W)                           # SKIP
                )
            else:
                T[n][W] = solve(n-1, W)                    # forced SKIP

            return T[n][W]

        return solve(n, W)

The diff from pure recursion to memoization is genuinely small: create the table, check before computing, store after computing. The structure of the solution doesn't change at all.

Step 6: Convert to Bottom-Up Tabulation

Memoization starts from the top and recurses down. Tabulation starts from the bottom and builds up. Both arrive at the same answer.

The connection between the two is direct:

The base cases from recursion become the initial values of the table
The recursive calls become table lookups
The n and W parameters become loop indices i and j

Since our base case was n == 0 or W == 0 → return 0, we initialise the entire table with zeros. Both base cases are handled in one line.

T = [[0] * (W + 1) for _ in range(n + 1)]

Then fill the table row by row, left to right, using the same transition from the recursive solution:

class Solution:

    def knapsack(self, W, val, wt):
        n = len(wt)

        # Initialise with zeros — base cases already handled
        T = [[0] * (W + 1) for _ in range(n + 1)]

        for i in range(1, n + 1):
            for j in range(1, W + 1):

                if wt[i-1] <= j:
                    T[i][j] = max(
                        val[i-1] + T[i-1][j - wt[i-1]],   # TAKE
                        T[i-1][j]                           # SKIP
                    )
                else:
                    T[i][j] = T[i-1][j]                    # forced SKIP

        return T[n][W]

The Complete Flow in One Picture

What the Table Cell Actually Means

This is the part worth pausing on because it makes every future DP table easier to read.

T[i][j] means: the maximum value achievable using the first i items with a bag capacity of exactly j.

So T[3][5] answers: "what's the best I can do with items 1, 2, and 3, if my bag holds 5 kg?" The final answer T[n][W] answers the original question: best value using all n items with full capacity W.

Every DP table you'll ever see has a similar interpretation. The indices represent the "state" of the problem at that point. Understanding what the indices mean is more important than knowing how to fill the table mechanically.

What This Pattern Unlocks

The 0/1 Knapsack pattern is not just one problem. It's a template.

0/1 Knapsack
      ↓
Subset Sum          — can we reach exactly a target weight?
      ↓
Equal Sum Partition — can we split into two equal subsets?
      ↓
Count of Subsets    — how many ways to reach a target sum?
      ↓
Min Subset Diff     — minimise the difference between two subsets
      ↓
Target Sum          — assign + and − to reach a target
      ↓
Count Subsets with Given Difference

Every problem in this list uses the same foundation: items, binary choices (take or skip), a state defined by the remaining items and remaining capacity, and a transition that combines answers from smaller states.

The surface details change. The underlying structure doesn't.

What You Now Understand

The 0/1 Knapsack solution was never about memorising a 2D array. It came from a choice diagram (take or skip), a base case (no items or no capacity), and a transition that said "take the maximum of both options."

Memoization stored the answers to avoid repeating work. Tabulation filled those same answers bottom-up without recursion. Both used the exact same transition.

Chapter 3 applies this pattern to Subset Sum, where the same take-or-skip logic solves a completely different-looking problem. If the pattern clicks here, Subset Sum will feel like a variation rather than something new.

Dynamic Programming Isn't Hard. You've Just Been Introduced to It Wrong.

Nishant Gaurav — Mon, 14 Sep 2026 10:34:42 +0000

Most people meet Dynamic Programming through a problem that looks like this: a 2D array, a nested loop, indices everywhere, and code that somehow produces a correct answer with no obvious explanation of why. They memorize the pattern, pass the interview, and still have no idea what DP actually is.

That's the wrong way in.

DP is not a coding pattern. It's a thinking pattern. And once you see what it's actually doing, the arrays and indices stop looking like magic and start looking like a natural consequence of a simple idea.

This is Chapter 1 of a series that builds DP from scratch. No tables yet. No 2D arrays. Just the mindset, the mental model, and the exact thinking process you'll use for every DP problem that follows.

The One Idea Behind All of DP

Dynamic Programming has one core insight:

If you've already solved a smaller version of a problem, don't solve it again. Store the answer and reuse it.

That's it. Everything else, the tables, the recursion, the memoization, is just machinery built around that idea.

How to Recognise a DP Problem

This is the question that matters most when you're starting out. Before worrying about tables or recursion, you need to know: is this even a DP problem?

Look for three things.

Choices. At some point in the problem, you face a decision. Take the item or skip it. Go left or go right. Cut here or cut somewhere else. The exact choices vary by problem, but there's always a fork.

Overlapping subproblems. When you draw out the recursion tree, the same smaller problem appears more than once. This is the signal that matters.

Optimal substructure. The best answer to the big problem is built from the best answers to its smaller pieces.

When you see a problem, ask yourself these questions in order:

Are there choices at each step?
        ↓
Can the problem be broken into smaller versions of itself?
        ↓
Do the same smaller versions appear more than once?
        ↓
Is the answer based on finding the best / count / possibility?

If the answer to these is yes, you're in DP territory.

The Learning Path We'll Follow

A lot of DP tutorials start with the table. That's like learning to drive by studying the engine. We're going the other way.

Every DP problem in this series will follow the same order:

We never jump to the table. We always start with the recursive thinking, identify where the wasted work is, and then apply DP to eliminate it.

Two Components That Drive Every Recursive Solution

Before you can convert recursion to DP, you need to write good recursion. Every recursive solution is built from exactly two things.

The Base Case

The base case answers one question: when do I stop?

More precisely: what is the smallest valid input for this problem, and what is its answer?

if n == 0:
    return 0

Here, n == 0 is the smallest problem we've decided to handle directly, and 0 is its answer. Before writing a single line of recursive logic, always ask: what is the smallest version of this problem, and what does it return?

The Choice Diagram

After the base case, ask: at the current step, what options do I have?

Take the classic 0/1 Knapsack problem. You're at item i with remaining capacity W. You have exactly two choices:

If wt[i] <= W:
    Choice 1 — TAKE:  Knapsack(i-1, W - wt[i])
    Choice 2 — SKIP:  Knapsack(i-1, W)

If wt[i] > W:
    Only option — SKIP: Knapsack(i-1, W)

The recursion is simply exploring these choices and returning the best result. Once you draw the choice diagram for any problem, the recursive code almost writes itself.

From Recursion to DP: Two Roads

Once you have a recursive solution, and you've confirmed the same subproblems are being solved repeatedly, you have two ways to fix it.

Top-Down (Memoization) keeps the recursive structure intact but adds a cache. Before computing a state, check if it's already been solved. If yes, return the stored answer. If no, compute it, store it, and return it.

# Conceptual memoization pattern
if dp[state] is not None:
    return dp[state]

# compute the answer
dp[state] = result
return dp[state]

Bottom-Up (Tabulation) flips the direction entirely. Instead of starting from the big problem and recursing down, you start from the smallest problems and build upward, filling a table until you reach the answer you need.

T[0][...] → T[1][...] → T[2][...] → ... → T[n][W]

Both approaches produce the same answer. Which one to use depends on the problem. We'll see both in action across the problems that follow in this series.

The Mental Model That Replaces Memorisation

Don't memorise: "DP means a 2D array."
Don't memorise: "Two recursive calls means DP."

Instead, carry this one flowchart in your head:

The table is just how you store answers. The real work is in recognising the repeated subproblems and drawing the choice diagram clearly before you write a single line of code.

What's Coming in This Series

This chapter covered the mindset. Everything that follows builds on it.

The series will move through problems in a deliberate order, starting simple and adding complexity layer by layer:

Recursion and Base Cases
        ↓
Memoization
        ↓
Tabulation
        ↓
0/1 Knapsack Pattern
        ↓
Subset Sum, Equal Partition, Count Subsets
        ↓
Unbounded Knapsack — Rod Cutting, Coin Change
        ↓
LCS, LIS, Kadane's Algorithm
        ↓
Interval DP, DP on Trees

Each problem in the series will follow the same nine-step order: understand the problem, identify choices, draw the choice diagram, find the base case, write recursion, find repeated states, add memoization, convert to tabulation, optimise if possible.

We never skip to step eight. That's the whole point.

What You Now Understand

DP is not about arrays or patterns you memorise before an interview. It's about recognising that you've seen a subproblem before and refusing to solve it twice.

The choices tell you the recursive structure. The base case tells you when to stop. The repeated states tell you where DP saves work. Everything else follows from those three things.

Chapter 2 starts with recursion problems that build the muscle for spotting choices and base cases before we introduce any DP optimisation at all. If recursion still feels shaky, that's exactly the right place to start.

You Use UPI Every Day. Here Is What Actually Happens in Those Two Seconds.

Nishant Gaurav — Tue, 23 Jun 2026 14:30:00 +0000

You scan a QR code. You enter your PIN. Two seconds later, the shopkeeper's phone buzzes. Money moved from your bank account to theirs, instantly, across potentially two completely different banks, with no cash, no card swipe, no delay.

Most people treat this as magic. It isn't. It's one of the most well-engineered payment infrastructures on the planet, and understanding how it works makes you appreciate both how clever the design is and why it occasionally fails the way it does.

This article walks through the full system: why UPI was invented, what the architecture looks like, which players are involved, and exactly what happens from the moment you scan a QR code to the moment that payment confirmation appears on screen.

The Problem UPI Was Built to Solve

Before UPI, sending money digitally in India was a painful chore. You had to juggle account numbers and IFSC codes, choosing between slow systems that took hours or fast ones that still required a long list of bank details, and making it way too frustrating for simple things like paying a street vendor or splitting a dinner bill.
UPI changed everything by replacing that entire mess with a single, easy-to-remember ID (like yourname@bankhandle) that sends money instantly. Turning that simple idea into something that works reliably for millions of people across hundreds of banks was the massive engineering challenge handed to the NPCI.

The Four Layers of the UPI Architecture

Before tracing a transaction, you need to understand who the players are. UPI has four distinct layers, each with a specific role.

Layer 1: The PSP App (Payment Service Provider)

This is the app on your phone. Google Pay, PhonePe, Paytm, and every other UPI app falls into this category. Their job is to provide the user interface: the screen where you scan the QR, enter the VPA, type the amount, and confirm with your PIN. They are the front end of the entire system.

What most people don't realise is that these apps have zero direct connection to the payment network. Google Pay cannot move money on its own. It has no banking license. It cannot talk to NPCI. To enter the actual payment network, each PSP app must partner with a bank.

Layer 2: The PSP Partner Bank

Every PSP app is backed by a partner bank that holds its UPI license and acts as the gateway into NPCI's network. Google Pay partners with Axis Bank, ICICI, HDFC, and SBI. PhonePe partners with Yes Bank, ICICI, and Axis. Paytm Payments Bank is its own entity.

When you initiate a payment in Google Pay, the app doesn't talk to NPCI. It talks to its partner bank, and that bank talks to NPCI. This distinction is important: NPCI trusts only licensed banks, not apps.

Layer 3: NPCI (National Payments Corporation of India)

NPCI is the backbone. It's not a payment gateway and not a bank. It is the infrastructure layer that makes the entire system possible. NPCI operates a closed, trusted network that only communicates with licensed member banks. No public API access. No direct integration for third parties. Every transaction flows through NPCI, and NPCI alone decides whether a transaction goes through.

Think of NPCI as the air traffic control system for money. It doesn't fly the planes, but nothing moves without its coordination.

Layer 4: The Issuing and Acquiring Banks

The issuing bank is where the sender's money lives. The acquiring bank is where the receiver's money goes. These are your regular banks: SBI, HDFC, ICICI, Kotak, and every other bank that has joined the UPI network. They hold the actual accounts and execute the debit and credit instructions that NPCI sends them.

What a VPA Actually Is

Before tracing the transaction flow, it helps to understand the VPA more concretely.

A VPA like john@oksbi or merchant@ybl is a pointer. It maps to a real bank account behind the scenes, but the sender never needs to know which account. NPCI maintains the mapping between VPAs and actual bank account details internally.

When you scan a QR code, you're not scanning anything exotic. A UPI QR code is just a VPA encoded in a standard format. Scanning it is the same as typing the VPA manually. The QR format exists purely to reduce the chance of typos.

Your VPA is registered when you set up UPI on any app. The app links your phone number, your bank account, and creates a VPA for you. The @handle part (like @oksbi, @ybl, @axl) identifies which PSP partner bank manages that VPA.

The Full Transaction Flow: What Happens When You Pay

Let's trace a complete transaction. You are paying a shopkeeper ₹500. You use PhonePe. Your account is at HDFC. The shopkeeper uses Google Pay and their account is at SBI.

Step 1: You create the payment intent

You open PhonePe and scan the shopkeeper's QR code. The app reads the VPA encoded in the QR, say shopkeeper@oksbi. You enter ₹500 and confirm. At this point, a payment intent is created inside the app: from your VPA, to shopkeeper@oksbi, amount ₹500.

Step 2: PhonePe forwards the request to its partner bank

PhonePe cannot touch NPCI directly. So it sends this payment intent to its PSP partner bank, which in this scenario is Yes Bank. The request includes your VPA, the destination VPA, the amount, and a unique transaction reference ID.

Step 3: Yes Bank forwards to NPCI

Yes Bank is a licensed member of NPCI's network. It takes PhonePe's payment request and forwards it to NPCI over the secure trusted network. NPCI now knows a payment has been initiated.

Step 4: NPCI resolves the VPAs and checks balance

NPCI looks up both VPAs internally. It identifies that your VPA points to an HDFC account and the shopkeeper's VPA points to an SBI account. NPCI then sends a request to HDFC asking: does this account have at least ₹500 available?

HDFC responds: yes.

Step 5: Authentication

NPCI sends back a challenge through the chain. Yes Bank passes it back to PhonePe, and PhonePe shows you the PIN entry screen. This is where you enter your UPI PIN. That PIN is not stored in the app. It is encrypted and sent back through the same chain to HDFC, which is the only entity that can verify it.

This is a critical security design. The PSP app, including Google Pay and PhonePe, never sees your actual PIN. It only passes the encrypted value through. Only your issuing bank (HDFC in this case) has the key to verify it.

Step 6: HDFC debits your account

Once HDFC validates your PIN, it debits ₹500 from your account and sends an acknowledgment back to NPCI confirming the debit was successful.

Step 7: NPCI credits the receiver's account

With the debit confirmed, NPCI instructs SBI to credit ₹500 to the shopkeeper's account. SBI does this and sends back an acknowledgment to NPCI.

Step 8: Both parties get notified

Only when NPCI receives acknowledgment from both banks (debit confirmed, credit confirmed) does it mark the transaction as complete. NPCI notifies Yes Bank, which notifies PhonePe, which shows you the success screen. Simultaneously, SBI notifies Google Pay (via ICICI, the shopkeeper's PSP partner bank), and the shopkeeper's phone buzzes.

The entire sequence takes roughly one to three seconds under normal conditions.

Why Transactions Fail (And Why Money Sometimes Comes Back)

The failure mode you've experienced: you pay, your account is debited, but the receiver says the money didn't arrive. This feels alarming, but the system handles it deliberately.

The transaction is only marked complete when NPCI receives acknowledgments from both the issuing bank (debit) and the acquiring bank (credit). If the acquiring bank's server is busy, overloaded, or temporarily unreachable, the credit acknowledgment never comes.

When NPCI doesn't receive acknowledgment within a timeout window, it initiates a rollback. It instructs the issuing bank to reverse the debit. Your money comes back. This is the reconciliation mechanism working correctly.

The delay between the debit and the reversal, sometimes minutes, sometimes a few hours for edge cases, is why it feels broken even when it isn't. The system is designed to never lose money in transit. Either both sides complete or neither side completes.

Why NPCI Exists Instead of Banks Talking Directly

You might reasonably ask: why not just have HDFC and SBI talk to each other directly? Why the intermediary?

Direct bank-to-bank integration doesn't scale. India has over 200 banks on the UPI network. If each bank had to maintain direct integrations with every other bank, that's potentially thousands of bilateral agreements, security audits, API contracts, and reconciliation systems. Every new bank joining the network would require bilateral connections with every existing member.

NPCI solves this with a hub-and-spoke model. Every bank integrates once with NPCI. NPCI handles the routing. When HDFC needs to send money to SBI, it doesn't need to know anything about SBI's systems. It just tells NPCI, and NPCI handles the rest.

This also centralises regulation and fraud detection. NPCI can monitor the entire transaction graph in real time, flag suspicious patterns, and enforce rules uniformly across the network without each bank building its own detection systems from scratch.

The Scale That Makes This Impressive

NPCI processed over 13 billion UPI transactions in a single month in 2024. That's roughly 5,000 transactions per second at peak load, with real-time settlement requirements, across hundreds of banks, with fault tolerance built in.

Building a system that handles that load while maintaining consistency (no double spends, no money lost in transit, no transaction completed partially) is a genuinely hard distributed systems problem. Every transaction requires coordinated state changes across at least two banks and NPCI simultaneously. If any one of them fails mid-transaction, the system has to roll back cleanly.

The fact that UPI works as reliably as it does, with failure rates that are low enough to be occasional annoyances rather than a reason to avoid the system, is a significant engineering achievement. Most of the internal implementation details of how NPCI manages this at scale are not publicly documented, which is both frustrating from a learning perspective and understandable from a security perspective.

Your Code Runs Locally. GitHub Actions Makes It Run Everywhere, Automatically.

Nishant Gaurav — Tue, 16 Jun 2026 14:30:00 +0000

You've pushed code to GitHub before. You know the drill: write something, commit it, push it, then manually do whatever comes next. Run the tests. Deploy the site. Update the docs. Every time, by hand.

GitHub Actions is the answer to "what if that next step just happened on its own?" It lets you define automated workflows that trigger whenever something happens in your repository. A push, a pull request, a schedule, even a manual button click. The workflow runs on GitHub's servers, not yours. You define the steps in a YAML file, commit it to your repo, and GitHub takes it from there.

This article walks through exactly how that works, using a real project as the example throughout: recLog, an automated pipeline that fetches articles from Dev.to and injects them into a portfolio's HTML without any manual update.

The Problem: Manual Steps After Every Push Don't Scale

Here's the situation that recLog was built to solve.

You write an article on Dev.to. You publish it. Now your portfolio is out of date because it lists your articles as static HTML that you maintain by hand. So you open your portfolio repo, copy in a new article card, adjust the HTML, commit, and push. Every. Single. Time.

This is fine once. It's annoying at ten articles. By twenty, you've already stopped doing it, which means your portfolio is quietly going stale while your actual writing keeps going.

The broader pattern is everywhere in software development. You push code and need to run tests before merging. You merge to main and need to deploy. You update a dependency and need to check if anything breaks. These are predictable, repeatable steps. Doing them manually introduces delay, inconsistency, and the very human tendency to skip them when you're in a hurry.

GitHub Actions turns these steps into automated workflows that live inside your repository. When the trigger fires, GitHub spins up a fresh machine, runs your defined steps in order, and reports back what happened. No server to maintain, no third-party CI tool to configure separately, no deploy keys to manage outside the repo.

How GitHub Actions Actually Works

The mental model

GitHub Actions is built around four concepts you need to understand before writing a single line of YAML: workflows, events, jobs, and steps.

A workflow is the top-level automation unit. It's a single YAML file that lives in .github/workflows/ inside your repository. One repo can have multiple workflow files, and each one is independent.

An event is what triggers the workflow. Push to main, open a pull request, publish a release, or run on a cron schedule. You define which events activate a given workflow in the on: block at the top of the file.

A job is a collection of steps that run together on the same machine. By default, jobs in the same workflow run in parallel. If one job depends on another, you declare that explicitly and GitHub sequences them accordingly.

A step is a single action within a job. It's either a shell command you write directly, or a pre-built action from the GitHub Actions marketplace that someone else wrote and you call by name.

Every job runs on a fresh virtual machine, called a runner, that GitHub provisions and discards after the job completes. This means each run starts from a clean state. Anything you need (dependencies, credentials, files from your repo) has to be explicitly set up within the workflow.

The workflow file

Here's the recLog workflow file, which is the actual file that keeps the portfolio in sync automatically:

# .github/workflows/main.yml

name: Sync Dev.to Articles

on:
  push:
    branches: [main]          # runs whenever code is pushed to main
  schedule:
    - cron: '0 */6 * * *'    # also runs every 6 hours automatically

jobs:
  sync:
    runs-on: ubuntu-latest    # GitHub provisions a fresh Ubuntu machine for this job

    steps:
      # Step 1: check out the repository so the runner has access to the code
      - name: Checkout repo
        uses: actions/checkout@v3

      # Step 2: install Python on the runner
      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.11'

      # Step 3: install the project's dependencies
      - name: Install dependencies
        run: pip install -r requirements.txt

      # Step 4: run the pipeline (fetch, deduplicate, inject)
      - name: Run sync pipeline
        run: python main.py
        env:
          DEVTO_API_KEY: ${{ secrets.DEVTO_API_KEY }}  # pulled from repo secrets, never hardcoded

      # Step 5: commit and push the updated index.html back to the repo
      - name: Commit updated portfolio
        run: |
          git config user.name "github-actions[bot]"
          git config user.email "github-actions[bot]@users.noreply.github.com"
          git add index.html
          git diff --staged --quiet || git commit -m "chore: sync articles $(date -u +%Y-%m-%dT%H:%M:%SZ)"
          git push

Walk through what this does. When code is pushed to main or when the 6-hour cron fires, GitHub provisions a fresh Ubuntu machine. It checks out the repository, installs Python 3.11, installs the dependencies from requirements.txt, runs main.py (which calls the Dev.to API, deduplicates articles against the existing HTML, and injects new cards), and then commits the updated index.html back to the repo. The portfolio updates without anyone touching it.

The git diff --staged --quiet || before the commit is worth noting. If main.py ran but found no new articles, index.html won't have changed. Without that check, the workflow would fail trying to commit a file with no changes. The || means: if the diff is empty (exit code 0), skip the commit.

How `uses` and `run` differ

You'll notice two kinds of steps in the file above.

Steps with uses: call a pre-built action. actions/checkout@v3 is maintained by GitHub and handles cloning your repo onto the runner correctly, including dealing with authentication. actions/setup-python@v4 installs Python and adds it to the runner's PATH. These are reusable building blocks from the Actions marketplace, versioned with the @v3 syntax so your workflow doesn't silently break when the action gets updated.

Steps with run: execute shell commands directly. This is where your own logic lives. Anything you'd type into a terminal, you can write here.

Secrets

Notice ${{ secrets.DEVTO_API_KEY }} in the workflow. This is how GitHub Actions handles credentials. You store the actual key value in your repository's Settings under Secrets and Variables, and reference it in the workflow using the ${{ secrets.NAME }} syntax. The value is never written to the workflow file, never visible in logs, and never committed to source control.

For recLog, this is where the Dev.to API key lives. The workflow reads it at runtime, passes it to the Python script as an environment variable, and the script uses it to authenticate against the Dev.to REST API.

The cron trigger

The schedule: event uses standard cron syntax. 0 */6 * * * means "at minute 0 of every 6th hour." GitHub runs this on UTC.

┌──── minute (0-59)
│  ┌─── hour (0-23)
│  │   ┌── day of month (1-31)
│  │   │  ┌─ month (1-12)
│  │   │  │  ┌ day of week (0-7, Sunday is 0 or 7)
│  │   │  │  │
0  */6  *  *  *

For recLog, this means the portfolio checks for new articles four times a day without any manual trigger. If you publish at 2am, the site reflects it by 8am at the latest.

Where It Gets Tricky

The runner starts empty every time

The runner GitHub provisions do not know your previous runs. It doesn't have your dependencies cached, it doesn't have your environment variables set, it doesn't have any state from the last time the workflow ran. This catches beginners every time.

If your script writes a file during one run and expects that file to exist on the next run, it won't. Everything ephemeral needs to either be committed back to the repo (like recLog does with index.html), stored in an external service, or regenerated each run.

For recLog this was a deliberate design choice. The deduplication logic reads the current state of index.html in the repo to know which articles already exist. The runner checks out the repo fresh each time, runs the diff, and commits only changes. The repo itself is the state store.

Workflow permissions for committing back

By default, the GITHUB_TOKEN that GitHub provides to each workflow run has read-only access to the repository contents. If your workflow tries to git push without the right permissions, it will fail with a 403.

To fix this, go to your repository Settings, then Actions, then General, and set "Workflow permissions" to "Read and write permissions." Alternatively, you can set it per-workflow in the YAML:

permissions:
  contents: write

This is one of the most common silent failure points for beginners writing their first workflow that commits back to the repo.

Cron schedules aren't guaranteed

GitHub's documentation states that scheduled workflows may be delayed during periods of high load on their infrastructure. A workflow scheduled for 6:00 UTC might run at 6:07, or occasionally later. For most use cases, this is fine. For anything where exact timing matters, scheduled Actions aren't the right tool.

There's also a lesser-known behaviour: GitHub will disable scheduled workflows on repositories that have had no activity for 60 days. If your portfolio repo goes quiet for two months, the sync stops. The fix is either to push something (anything) to keep the repo active, or to trigger the workflow manually from the Actions tab when you notice it's stopped.

Secrets in forks and pull requests

If someone forks your repo and opens a pull request, workflows triggered by that PR will not have access to your repository secrets. This is a security measure, not a bug. It means a fork-based PR can't exfiltrate your API keys. But it also means if your workflow requires a secret to run, it will fail on PRs from forks. Keep this in mind if you ever open-source a project that has required secrets in its workflow.

Building recLog's Pipeline Step by Step

Here's how to set up a workflow like recLog's from scratch, assuming you have a repository with a Python project that you want to automate.

Step 1: create the workflow directory

mkdir -p .github/workflows

Step 2: write the workflow file

Create .github/workflows/main.yml and start with the trigger and job definition:

name: Sync Dev.to Articles

on:
  push:
    branches: [main]
  schedule:
    - cron: '0 */6 * * *'

jobs:
  sync:
    runs-on: ubuntu-latest

Step 3: add the checkout and Python setup steps

These two steps appear in nearly every Python-based workflow. The checkout action clones the repo onto the runner. Without it, the runner has no access to your code.

    steps:
      - name: Checkout repo
        uses: actions/checkout@v3

      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.11'

Step 4: install dependencies and run your script

      - name: Install dependencies
        run: pip install -r requirements.txt

      - name: Run sync pipeline
        run: python main.py
        env:
          DEVTO_API_KEY: ${{ secrets.DEVTO_API_KEY }}

Step 5: add the secret to your repository

Go to your repository on GitHub. Settings, then Secrets and variables, then Actions, then "New repository secret." Name it DEVTO_API_KEY and paste in your Dev.to API key. The workflow will now have access to it at runtime.

Step 6: commit and push if the output changed

This is the step that closes the loop. The git diff --staged --quiet || guard ensures the commit only runs when there's actually something new to commit:

      - name: Commit updated portfolio
        run: |
          git config user.name "github-actions[bot]"
          git config user.email "github-actions[bot]@users.noreply.github.com"
          git add index.html
          git diff --staged --quiet || git commit -m "chore: sync articles $(date -u +%Y-%m-%dT%H:%M:%SZ)"
          git push

Once this file is committed and pushed to main, GitHub picks it up automatically. You'll see the workflow appear in the Actions tab of your repository. Every run shows the status of each step, the logs, and how long it took.

What You Now Understand

A GitHub Actions workflow is not magic. It's a YAML file that tells GitHub: when this event happens, spin up a machine, run these steps in order, and report back. Every concept in that sentence is something you now have a working mental model of: events, runners, steps, secrets, and how to commit results back to the repo.

The recLog pipeline is a clean example of the pattern in its simplest useful form: trigger on push and on schedule, run Python, commit the output. That structure applies directly to dozens of other automation problems: syncing data, running tests, publishing packages, and generating reports.

Your next step is to open the Actions tab on any of your existing GitHub repositories and look at the starter workflows GitHub suggests. Pick the simplest one that applies to your stack, read through it line by line against what you've learned here, and run it. Seeing a green checkmark on your first workflow is how the mental model becomes a reflex.

GitHub Already Knows When You Push. It Can Do a Lot More Than Just Watch.

Nishant Gaurav — Wed, 10 Jun 2026 14:30:00 +0000

Every time you push code to GitHub, something happens on their end. A record is created, your repo updates, collaborators can see the change. GitHub is already reacting to your push. The question is whether you want it to stop there, or do something useful with that event.

That's the idea behind GitHub Actions. It's GitHub's built-in automation layer. When something happens in your repository, a workflow runs. That workflow can test your code, deploy your app, send a notification, sync data, or do anything else a computer can do. No external service required. No separate CI tool to configure. It lives inside your repo, runs on GitHub's infrastructure, and triggers off the same events your repository already produces.

Why GitHub Built This When AWS Already Exists

This is a fair question. AWS CodePipeline, Jenkins, CircleCI, and a dozen other tools already handle CI/CD. Why did GitHub build their own?

The honest answer is friction. Every existing tool required you to leave GitHub, set up an account somewhere else, connect it to your repo via webhooks or API tokens, configure a pipeline in a separate interface, and then debug failures across two different platforms. For large engineering teams with dedicated DevOps engineers, that cost is manageable. For an individual developer or a small team, it's enough friction to skip automation entirely.

GitHub Actions removes the "leave GitHub" part. Your workflow file lives in .github/workflows/ inside your repo. It's version-controlled alongside your code. You see the results in the same tab where you see your commits and pull requests. When something breaks, the logs are right there.

AWS and other cloud platforms are still the right choice when you need deep infrastructure control, complex deployment pipelines across multiple environments, or tight integration with AWS-specific services. GitHub Actions is not trying to replace that. It's solving a different problem: making basic automation accessible to anyone who already uses GitHub, without requiring infrastructure expertise to get started.

How It Actually Works

GitHub Actions is built on four concepts. Understand these and everything else is just syntax.

Workflows are the top-level unit. Each workflow is a YAML file in .github/workflows/. One repository can have multiple workflows, and each one is completely independent.

Events are what trigger a workflow. A push to main, a pull request being opened, a release being published, or a scheduled time. You define which events activate a workflow in the on: block at the top of the file.

Jobs are groups of steps that run together on the same machine. Multiple jobs in a workflow run in parallel by default. If one job needs the output of another, you declare that dependency explicitly.

Steps are individual tasks within a job. A step is either a shell command you write directly using run:, or a pre-built action from the marketplace that you call using uses:.

Every job runs on a fresh virtual machine that GitHub provisions for the duration of the job and discards afterward. This machine is called a runner. The most common choice is ubuntu-latest. The runner starts with nothing except a base OS, so anything your workflow needs (Python, Node, dependencies, credentials) has to be set up explicitly within the steps.

Your First Workflow

Here's a minimal workflow that runs your Python tests automatically every time code is pushed to the main branch:

# .github/workflows/ci.yml

name: Run Tests

on:
  push:
    branches: [main]      # triggers on every push to main

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v3      # clones your repo onto the runner

      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.11'

      - name: Install dependencies
        run: pip install -r requirements.txt

      - name: Run tests
        run: pytest

To use this, create the file at .github/workflows/ci.yml in your repo, commit it, and push. GitHub picks it up automatically. Go to the Actions tab in your repository and you'll see the workflow run in real time.

That's it. No external accounts. No webhooks to configure. The workflow file being in the right directory is all GitHub needs.

Secrets: Credentials Without Hardcoding

Almost every real workflow needs a credential of some kind: an API key, a deploy token, a database password. You should never write these directly in your workflow file, because workflow files are committed to your repository and potentially public.

GitHub solves this with secrets. You store the value in your repository settings (Settings, then Secrets and variables, then Actions), and reference it in the workflow using ${{ secrets.YOUR_SECRET_NAME }}. The value is masked in logs and never exposed in the workflow file itself.

      - name: Call external API
        run: python sync.py
        env:
          API_KEY: ${{ secrets.API_KEY }}    # injected at runtime, never hardcoded

Where GitHub Actions Fits (and Where It Doesn't)

GitHub Actions handles most automation needs for individual projects and small teams well: running tests on pull requests, deploying static sites, syncing data on a schedule, publishing packages on release. The setup cost is low and the integration with GitHub is tight.

It starts showing limits when you need long-running jobs (there's a 6-hour cap per job), complex multi-environment deployments with approval gates, or workloads that need dedicated infrastructure rather than ephemeral runners. For those cases, dedicated platforms like AWS CodePipeline or a self-hosted Jenkins instance are still the right tool.

For most projects, though, GitHub Actions covers what you need without requiring you to leave the platform you're already using.

Setting Up Your First Workflow: The Short Version

In your repository, create the directory .github/workflows/
Add a YAML file inside it (the name can be anything, e.g. ci.yml)
Define your trigger in the on: block
Define a job with runs-on: ubuntu-latest
Add steps using uses: for marketplace actions and run: for shell commands
Commit and push. Check the Actions tab.

Any secrets your workflow needs go in Settings, then Secrets and variables, then Actions, referenced in the workflow as ${{ secrets.NAME }}.

What Comes Next

Once this mental model is solid, the natural next step is building a workflow that actually does something specific to your project: runs your test suite, deploys on merge, or automates a repetitive task you currently do by hand.

A deeper walkthrough of a complete real-world pipeline (fetching data, transforming it, committing the result back to the repo automatically) is covered in the follow-up article: Building an Automated Content Pipeline with GitHub Actions.

The foundation is what this article covered. The follow-up shows what it looks like when you apply it to a production project from start to finish.

You Don't Have a "Works on My Machine" Problem. You Have a Dependency Problem.

Nishant Gaurav — Mon, 08 Jun 2026 05:53:48 +0000

Every developer has said it. You write code, it runs perfectly on your laptop, you push it to a server or hand it to a teammate, and something breaks. Wrong Python version. A library installed globally that you forgot about. An environment variable that was set in your shell profile but nowhere else.

Docker doesn't fix your code. It fixes the gap between the environment where you wrote your code and the environment where it runs. That's the whole job. And once you see that clearly, everything else about Docker follows logically.

The Problem: Environments Are Invisible Dependencies

Here's a scenario that plays out constantly on engineering teams.

A developer builds a data processing script. It works on their machine. They hand it to a teammate. The teammate runs it and it crashes because a library is the wrong version, or isn't installed at all. So they spend an hour aligning their setups. Two weeks later, it's deployed to production. It crashes again because the server is running a different OS version, and a native dependency that compiled fine locally doesn't compile there.

None of this is a code problem. The code is fine. The problem is that every machine carries hidden state: installed packages, runtime versions, system libraries, OS quirks. And your application depends on all of it, invisibly.

The traditional solutions are painful. You write a requirements.txt or a package.json and hope everyone runs it. You write a setup script. You document the expected environment in a README that gets out of date. You use a virtual environment, which helps for language-level dependencies but doesn't capture system-level ones. You use a VM, which captures everything but is heavy, slow to start, and awkward to share.

Docker solves this by packaging the application and its entire environment (OS libraries, runtime, config, dependencies) into a single portable unit. That unit runs the same way everywhere Docker is installed.

How Docker Actually Works

The core idea: containers vs virtual machines

The most common misconception about Docker is that it's a lightweight virtual machine. It isn't, and the difference matters.

A virtual machine emulates hardware. When you run a VM, your computer pretends to be a different computer, running a full operating system on top of fake hardware. That's expensive. A VM typically takes seconds to minutes to start and consumes gigabytes of RAM just for the OS layer.

Docker uses a different mechanism called containerisation. Containers don't emulate hardware. They run as isolated processes directly on your actual OS kernel, using two Linux features to create the illusion of separation.

Namespaces give each container its own view of the system. A container has its own process list, its own network interfaces, its own filesystem tree. From inside the container, it looks like it's the only thing running.

cgroups (control groups) limit how much CPU, memory, and I/O a container can consume. This is how Docker prevents one container from starving others.

Because containers share the host kernel rather than running their own, they start in milliseconds and use a fraction of the memory a VM would. A container running a Python web app might consume 50MB of RAM. A VM running the same app would consume 50MB for the app plus roughly 500MB for the guest OS.

Images and containers

Docker has two concepts you need to keep straight: images and containers.

An image is a read-only template. It describes an environment: which OS layer to use, which packages to install, which files to include, which command to run on startup. An image is not running anything. It's a blueprint, like a class definition in code.

A container is a running instance of an image. When you tell Docker to run an image, it creates a container: a live, isolated process using that image as its starting state. You can run ten containers from the same image simultaneously and each will be isolated from the others. This is the class-vs-object analogy made literal.

Images are built in layers. Every instruction in your image definition adds a layer on top of the previous one: start with a base OS layer, add a Python layer, add your application code. Docker caches each layer separately. If you rebuild an image after changing only your application code, Docker reuses the OS and Python layers from cache and only rebuilds the final layer. This makes rebuilds fast.

The Dockerfile

You define an image with a Dockerfile, a plain text file that lists the build instructions.

# Start from an official Python base image (OS + Python bundled together)
FROM python:3.11-slim

# Set the working directory inside the container
WORKDIR /app

# Copy and install dependencies first so this layer gets cached
# as long as requirements.txt doesn't change
COPY requirements.txt .
RUN pip install -r requirements.txt

# Now copy your application code (this layer rebuilds on every code change)
COPY . .

# Tell Docker what to run when the container starts
CMD ["python", "app.py"]

The ordering here is deliberate. requirements.txt is copied and installed before the application code. Because Docker caches layers, if you change your code but not your dependencies, Docker will reuse the cached dependency layer and only redo the final COPY. If you put COPY . . first, every code change would invalidate the dependency cache and reinstall everything, turning a two-second rebuild into a two-minute one.

The Docker Hub and base images

You don't build images from scratch. You start FROM an existing image, usually an official one from Docker Hub, which is a public registry of images. python:3.11-slim is an image that includes Debian Linux and Python 3.11, maintained by the Python team. There are official base images for nearly every language runtime, database, and common tool.

The slim suffix is a convention for smaller variants that strip out documentation and tools you don't need at runtime. For production use, smaller images mean faster deploys and a smaller attack surface.

Docker Compose

A real application is rarely just one container. You have your app, a database, maybe a caching layer. Docker Compose lets you define and manage multiple containers as a single unit.

# docker-compose.yml defines a web app and its database together
services:
  web:
    build: .                    # build from the Dockerfile in this directory
    ports:
      - "8000:8000"             # map port 8000 on your machine to port 8000 in the container
    depends_on:
      - db                      # don't start web until db is running
    environment:
      DATABASE_URL: postgres://user:pass@db:5432/mydb

  db:
    image: postgres:15          # use the official Postgres image directly
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: pass
      POSTGRES_DB: mydb

With this file in your project, docker compose up starts both containers with the right configuration. A new developer on your team clones the repo and runs one command. No database installation required.

Where It Gets Complicated

Persistence: containers are ephemeral by default

A container's filesystem is disposable. When you delete a container, anything written inside it is gone. For a stateless web app that's fine because you rebuild and redeploy. For a database, it's a disaster.

Docker handles this with volumes: directories on your host machine (or a managed storage backend) that get mounted into containers. Anything the container writes to the volume path persists even after the container is removed.

Beginners consistently skip volumes when running databases locally, then wonder why their data disappears every time they restart. Add this to your Compose file for the database:

db:
  image: postgres:15
  volumes:
    - postgres_data:/var/lib/postgresql/data   # named volume for persistence

volumes:
  postgres_data:   # declare the named volume

Image size creep

The single most common mistake when writing Dockerfiles is producing images that are far larger than they need to be. A Python image built naively can easily reach 1-2GB. The production version of the same app can be under 100MB with multi-stage builds.

Multi-stage builds let you use one image to build your application (with compilers, test tools, all of it) and a separate, leaner image to run it. The final image only contains what the runtime needs.

# Stage 1: build stage with full tooling
FROM python:3.11 AS builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --prefix=/install -r requirements.txt

# Stage 2: runtime stage, slim and minimal
FROM python:3.11-slim
WORKDIR /app
COPY --from=builder /install /usr/local   # copy only the installed packages
COPY . .
CMD ["python", "app.py"]

Secrets and environment variables

Don't put secrets in your Dockerfile. If you write ENV API_KEY=abc123 in a Dockerfile and push it to a registry, that key is baked into every layer of the image and visible to anyone who pulls it.

Pass secrets at runtime using environment variables, Docker secrets, or a tool like Vault. Your Compose file can reference variables from a .env file that you never commit to source control.

Networking between containers

Containers on the same Docker network can reach each other by service name. In the Compose example above, the web app connects to db:5432. The name db is not a hostname you configured anywhere. Docker's internal DNS resolves it to the database container automatically. This trips up beginners who try to use localhost inside a container and can't reach a sibling container. Inside a container, localhost refers to that container, not the host machine or anything running alongside it.

A Concrete Scenario: Onboarding Without the Setup Tax

Here's where the value becomes tangible. You're working on a team building a backend API in Python. The app needs Python 3.11, PostgreSQL 15, and Redis. Without Docker, onboarding a new engineer means installing Python 3.11 (maybe using pyenv, maybe not), installing and configuring PostgreSQL, installing Redis, setting a dozen environment variables, and running migrations. This takes anywhere from 30 minutes to half a day, and something always breaks on someone's machine.

With Docker, the repository contains a docker-compose.yml and a .env.example. The onboarding instruction is two commands:

cp .env.example .env
docker compose up

The first run downloads base images, which takes a few minutes once. Every subsequent run starts in under five seconds. The entire environment (exact Python version, exact Postgres version, exact Redis version, correct config) is encoded in files that live in version control alongside the application code.

When you upgrade from PostgreSQL 15 to 16, you change one line in docker-compose.yml and commit it. Every developer on the team gets the upgrade on their next pull. No announcement in Slack. No "make sure you've upgraded your local Postgres" in the README.

This is Docker's most underrated value for teams. The environment becomes a first-class artifact of the project, versioned, reproducible, and reviewable just like the code.

What You Now Understand

The phrase "it works on my machine" describes a configuration management failure, not a code problem. Docker's answer is to make the environment part of the artifact, not documented alongside it but included inside it.

That's the shift. Not "write better setup instructions." Bundle the setup into something that runs.

Your concrete next step: take an existing project, a simple web app or a script, and write a Dockerfile for it. Don't worry about making it production-perfect. Get it building and running locally. The feedback loop of seeing what breaks and why is how this becomes intuition rather than theory.

Once you're comfortable with that, the natural next steps are multi-stage builds for smaller production images, volumes for stateful workloads, and eventually Kubernetes for running containers across multiple machines. But those are layers built on top of this foundation. Get the foundation first.

How to Build a Portfolio Website From Scratch – A Complete Journey

Nishant Gaurav — Fri, 13 Feb 2026 20:22:01 +0000

PART 1: The Full Journey

Preview: Light Mode

1. When I Started Building My Portfolio

When I decided to build my portfolio, I knew I didn’t want it to look like a “template-based” website. I wanted my site to show who I was as a developer: organized, clean, and systematic.

So long before I wrote even one line of code, I planned:

The sections I wanted to show on my portfolio.
How do recruiters view portfolios?
What is shown at the top of my portfolio (above the fold).
How to balance content with images on my portfolio.

The final structure is as follows:

Navbar
Hero / About
Projects
Skills
Achievements & Certifications
Contact
Footer

Goal:
“If someone spends 30 seconds on my site, they should be able to identify who I am technically.”

2. Structuring the HTML Layout

I built everything using semantic HTML + Bootstrap grid.

Each section was wrapped inside a <section> tag:

<section id="about"></section>
<section id="projects"></section>
<section id="skills"></section>

This allowed me to achieve:

Anchor navigation
SEO-friendly structure
Clean scroll targeting

Layout scaffolding:

<div class="container">
  <div class="row">
    <div class="col-md-6"></div>
  </div>
</div>

Bootstrap handled responsiveness, while custom CSS handled visual identity.

3. Designing the Navbar

Since the navbar is the first thing people see when they enter the application, it was important for me to keep it in the following ways:

Fixed at the top
Minimal
Navigation-focused

Key decisions:

Logo + Name branding
Anchor navigation links
Theme toggle switch

<nav class="navbar navbar-expand-lg fixed-top custom-header">

Hover animation:

.navbar-nav .nav-link::after {
  width: 0;
  transition: width 0.3s ease;
}

4. Building the Hero / About Section

This section had to communicate:

Who I am
What I do
What I’ve achieved

Two-column layout:

<div class="row align-items-center">
  <div class="col-md-5">Image</div>
  <div class="col-md-7">Content</div>
</div>

UI decisions:

Rounded profile image
Shadow wrapper
Using GIFs for accents.
Using bold text for highlights.
Resume links

.about_img--wrapper {
  box-shadow: 0 6px 18px rgba(0,0,0,0.1);
}

5. Projects Section: Card Architecture

I designed projects as product tiles.

<div class="col-md-6 col-lg-4">
  <div class="project-card"></div>
</div>

Design decisions:

25px radius
Muted teal background
Hover lift

.project-card:hover {
  transform: translateY(5px);
}

6. Skills Section: Visualizing Competence

Custom progress bars:

<div class="skill-bar">
  <div class="skill-fill" style="width:85%"></div>
</div>

.skill-bar { background: #7c8d8f; }
.skill-fill { background: #1f2022; }

Split into two columns for balance.

7. Achievements & Certifications:

Image-driven proof cards.

.achievement-img-wrapper {
  height: 260px;
  overflow: hidden;
}

Hover zoom:

.achievement-card:hover .achievement-img {
  transform: scale(1.05);
}

8. Contact Section:

Two layers:
Quick Links

LinkedIn
Email
GitHub

Contact Form

<form>
  <input type="text">
  <textarea></textarea>
</form>

Hover elevation:

.contact-card:hover {
  transform: translateY(5px);
}

9. Footer: Closing Identity

Logo
Copyright
Social icons

.footer-icon:hover {
  transform: scale(1.1);
}

10. Dark & Light Mode Implementation:

Theme toggle via JS & Persistence:

toggleBtn.addEventListener("change", () => {
  body.classList.toggle("dark-mode");
});

localStorage.setItem("theme","dark");

Dark Mode

Dark-Mode Decisions:

body.dark-mode {
  background-color: #0f1115;
  color: #e6e6e6;
}

Adjustments:

Gradient cards
Teal skill bars
Dark inputs

Goal: Reduce eye strain.

11. Layout Engineering:

Bootstrap Grid → Structure
Flexbox → Alignment

display: flex;
align-items: center;

12. Color & Typography:

Palette:

#7eaeb4 Accent
#393E46 Dark
#f4f5f7 Light

.card-title {
  font-family: 'Courier New';
}

13. Responsiveness:

@media (max-width: 767px) {
  .skill-bar { height: 12px; }
}

14. Challenges:

Dark mode contrast
Card consistency
Image scaling
Navbar shadows

15. Micro-UI Decisions:

Hover lifts
Underline nav animation
Skill transitions
Icon scaling
Section accents

PART 2: What I Learned

HTML Semantics

<section id="projects"></section>

CSS Positioning

position: fixed;

Flexbox

display: flex;

Grid

<div class="row"></div>

Responsive Design

img { max-width: 100%; }

Media Queries

@media (max-width:768px) {}

Theme Switching

localStorage.setItem("theme","dark");

Clean UI Principles

Spacing
Contrast
Hierarchy

Final Reflection

This portfolio became more than a website.

It taught me:

UI architecture
Theme systems
Responsive thinking
Developer storytelling

And it represents me better than any resume.