DEV Community: Tarang

A classic linked list problem: reorder the list (mental model and dry run)

Tarang — Sun, 04 Oct 2026 17:10:37 +0000

Reorder the linked list

A classic linked list problem — one exercise that brushes several core ideas at once:

finding the middle (slow / fast pointers)
reversing a chain in place
merging two lists by rewiring next pointers

Problem

Given the head of a singly linked list, the list can be written as:

L0 → L1 → … → Ln-1 → Ln

Reorder it to:

L0 → Ln → L1 → Ln-1 → L2 → Ln-2 → …

Example with numbers:

1 → 2 → 3 → 4 → 5   becomes   1 → 5 → 2 → 4 → 3
1 → 2 → 3 → 4       becomes   1 → 4 → 2 → 3

Mental model: three steps

step 1: find the middle of the list
step 2: reverse the second half
step 3: merge the two halves

   L0 → L1 → … → slow | slow.next → … → Ln
        |
        +-- firstll                    secondll (then reversed)
        |
        v
   zip: L0 → Ln → L1 → Ln-1 → …

After step 1 you have firstll (head) and secondll (slow.next). Set slow.next = null so the list is cut in two. Step 2 makes secondll start at the old tail. Step 3 alternates links between firstll and secondll.

Step 1 — Find the middle (dry run)

Code shape:

let slow = head;
let fast = head;
while (fast && fast.next) {
  fast = fast.next.next;
  if (!fast) {
    break;
  }
  slow = slow.next;
}
let firstll = head;
let secondll = slow.next;
slow.next = null;

Move fast two steps first. Only if fast is still non-null do you move slow one step. If fast becomes null, stop without moving slow again.

Odd: `1 → 2 → 3 → 4 → 5`

Loop	fast after `fast = fast.next.next`	slow after	stop?
start	1	1
1	3	2
2	5	3
3	null	3	`break` (slow unchanged)

firstll: 1 → 2 → 3 (slow.next = null)
secondll: 4 → 5

Even: `1 → 2 → 3 → 4`

Loop	fast after jump	slow after	stop?
start	1	1
1	3	2
2	null	2	`break`

firstll: 1 → 2
secondll: 3 → 4

Step 2 — Reverse secondll (dry run)

Same loop as in your code: curr, prev, future.

let curr = secondll;
let prev = null;
let future;
while (curr) {
  future = curr.next;
  curr.next = prev;
  prev = curr;
  curr = future;
}
secondll = prev;

Starting from 4 → 5 (odd example)

curr	future	after `curr.next = prev`	prev	curr next
4	5	null ← 4	4	5
5	null	null ← 4 ← 5	5	null

secondll = prev → 5 → 4

Starting from 3 → 4 (even example) → 4 → 3

Step 3 — Merge (dry run)

let firstllnext;
let secondllnext;
while (firstll && secondll) {
  firstllnext = firstll.next;
  secondllnext = secondll.next;

  firstll.next = secondll;
  secondll.next = firstllnext;

  firstll = firstllnext;
  secondll = secondllnext;
}

Each iteration: save both .next, plug second right after first, put the saved first .next after second, then walk both pointers forward.

Odd example — after step 1 and 2

firstll:  1 → 2 → 3
secondll: 5 → 4

Round	firstll	secondll	wires	list from head
start	1	5		two separate chains
1	2	4	1→5, 5→2	`1 → 5 → 2 → 3` and `4`
2	3	null	2→4, 4→3	`1 → 5 → 2 → 4 → 3`
done	3	—	loop ends	`1 → 5 → 2 → 4 → 3`

When secondll is null, 3 is already the tail. No extra work.

Even example

firstll:  1 → 2
secondll: 4 → 3

Round	firstll	secondll	list from head
1	2	3	`1 → 4 → 2` and `3`
2	null	null	`1 → 4 → 2 → 3`

Full solution (JavaScript)

var reorderList = function (head) {
  let slow = head;
  let fast = head;
  while (fast && fast.next) {
    fast = fast.next.next;
    if (!fast) {
      break;
    }
    slow = slow.next;
  }
  let firstll = head;
  let secondll = slow.next;

  slow.next = null;

  let curr = secondll;
  let prev = null;
  let future;
  while (curr) {
    future = curr.next;
    curr.next = prev;
    prev = curr;
    curr = future;
  }
  secondll = prev;

  let firstllnext;
  let secondllnext;
  while (firstll && secondll) {
    firstllnext = firstll.next;
    secondllnext = secondll.next;

    firstll.next = secondll;
    secondll.next = firstllnext;

    firstll = firstllnext;
    secondll = secondllnext;
  }
  return firstll;
};

The list is reordered in place starting from head. The return value is not what you use; the rewired nodes from head are the answer.

What to remember

Step	Variables in your code
Middle	`slow`, `fast`, then `firstll` / `secondll`, cut with `slow.next = null`
Reverse	`curr`, `prev`, `future` → `secondll = prev`
Merge	`firstllnext`, `secondllnext`, alternate `.next`

The pattern is always: split → reverse the back → zip.

REST API methods and DNS, in one place

Tarang — Sat, 03 Oct 2026 18:57:31 +0000

Two pieces of the same web

Browsers and apps need two different kinds of answers:

REST — what action to take on data (read, create, replace, change a part, delete).
DNS — which server on the internet owns a name like www.instagram.com.

This post covers both. They do not depend on each other, but you meet them on almost every project.

REST API methods

A REST API exposes resources (users, orders, posts) at URLs. The HTTP method tells the server what to do with that resource.

Method	Role	Typical use
GET	Read	Fetch data without changing it
POST	Create	Add a new resource
PUT	Replace	Swap the whole resource at that URL
PATCH	Partial update	Change some fields only
DELETE	Remove	Delete the resource

All of these usually run over HTTPS on top of TCP.

GET — get the data

GET is for reading. It should not create, update, or delete on the server.

GET /students/345 HTTP/1.1
Host: api.example.com

The response might be JSON with the student’s name and section. Safe to retry: calling GET twice does not change the database.

POST — create

POST creates something new. The client sends a body; the server assigns an id and stores a new row.

POST /students HTTP/1.1
Content-Type: application/json

{"name": "Asha", "section": "B"}

POST is not for replacing an existing student in one shot. It is for adding a new record. POST is not idempotent: sending the same POST twice often creates two students unless the API has extra rules.

PUT — replace the whole resource

PUT means “here is the full new version at this URL.” If student 345 exists, PUT overwrites all fields you model at that URL. Missing fields might become empty or default, depending on the API design.

PUT /students/345 HTTP/1.1
Content-Type: application/json

{"name": "Asha", "section": "C"}

PUT is for replace, not “create with auto id” in the usual REST style. Some APIs allow PUT to create when the client chooses the id in the path; POST is still the usual way to create with a server-generated id.

PUT is idempotent: repeating the same PUT leaves the resource in the same state.

PATCH — replace part of the data

PATCH updates only what you send. Change the section without resending the whole student.

PATCH /students/345 HTTP/1.1
Content-Type: application/json

{"section": "C"}

Name and other fields stay as they were. Use PATCH when the client should not need to read the full object, change one field, and PUT everything back.

DELETE — delete the data

DELETE removes the resource at that URL.

DELETE /students/345 HTTP/1.1

After a successful delete, GET /students/345 might return 404 Not Found.

Quick comparison

POST   → new resource        (create)
GET    → read                 (no change)
PUT    → whole resource       (full replace)
PATCH  → part of resource     (partial update)
DELETE → remove resource

DNS — Domain Name System

DNS (Domain Name System) turns hostnames people type into IP addresses computers use to connect. It is a distributed lookup system, not a single registry file on one machine.

When someone opens www.instagram.com:

The browser asks the OS for that name.
The OS asks a recursive resolver (often from your ISP or 8.8.8.8).
The resolver walks the DNS hierarchy — root → .com → instagram.com → www — and finds a record such as an A record (IPv4) or AAAA (IPv6).
The browser opens HTTPS to that IP. TLS still checks the certificate matches www.instagram.com.

user types www.instagram.com
        |
        v
   DNS lookup  ----->  returns e.g. 157.240.x.x
        |
        v
   TCP + TLS + HTTP to that server

Registering a domain (buying example.com) is a separate step from day-to-day DNS. A registrar records that you own the name. You (or your host) publish DNS records that say which IP or CDN serves www and mail. Those records live on authoritative name servers for your zone. The world’s resolvers cache answers for a while (TTL) so not every click hits the root.

Common record types:

Record	Meaning
A / AAAA	Hostname → IP address
CNAME	Alias → another hostname
MX	Mail for the domain

Without DNS, you would need to remember numeric IPs for every site. With DNS, you remember the name; the system routes you to the right server.

Side by side

Topic	Question it answers
REST methods	What should the server do to this resource?
DNS	Which machine lives at this hostname?

A mobile app might GET /feed on api.instagram.com. DNS is what resolved api.instagram.com before the GET ever left the phone.

Types of connections: HTTP, TLS, WebSocket, gRPC, TCP, and UDP

Tarang — Sat, 03 Oct 2026 18:35:28 +0000

What are types of connections?

When two programs talk over a network, they agree on layers. The transport layer moves bytes reliably or quickly. The application layer is the language those bytes mean: a web page, a chat message, a remote procedure call.

Keep two levels in mind:

Level	Examples	Job
Application	HTTP, HTTPS, WebSocket, gRPC	What the conversation is about
Transport	TCP, UDP	How bytes get from client to server

Application protocols usually sit on top of TCP or UDP. HTTPS and WebSocket still use TCP underneath.

TCP: the three-way handshake

TCP (Transmission Control Protocol) is connection-oriented. Before data flows, client and server agree the link is open. That agreement is the three-way handshake.

The handshake is three messages: SYN → SYN-ACK → ACK.

client                          server
   |---- SYN -------------------->|
   |<--- SYN-ACK -----------------|
   |---- ACK -------------------->|
   |         connection ready      |

SYN — client asks to open a connection
SYN-ACK — server agrees and responds
ACK — client confirms

After this, both sides can send data. TCP also re-sends lost packets and keeps order. That reliability costs a little latency compared to UDP.

HTTP, HTTPS, WebSocket, and gRPC (over HTTP/2) typically use TCP.

UDP: no handshake, no guarantee

UDP (User Datagram Protocol) is connectionless. The client sends datagrams (packets) without opening a session first. There is no three-way handshake. The server does not send an ACK for every packet the way TCP does.

UDP is faster and lighter. It fits live video, DNS lookups, and games where a lost frame is acceptable. If you need every byte and strict order, use TCP.

HTTP

HTTP (Hypertext Transfer Protocol) is the application protocol of the web. A client sends a request (method, path, headers). A server sends a response (status code, headers, body).

HTTP runs on TCP, usually port 80. Each request is often a short conversation: connect, ask, answer, done. HTTP/1.1 can reuse one TCP connection for several requests.

Example shape (not full syntax):

GET /students/345 HTTP/1.1
Host: example.com

The server returns HTML or JSON. Plain HTTP is not encrypted. Anyone on the path can read usernames, passwords, and cookies.

HTTPS: HTTP with TLS

HTTPS is HTTP wrapped in TLS (Transport Layer Security). TLS encrypts traffic above TCP and below HTTP.

Older docs say SSL; today we say TLS (TLS 1.2 and 1.3 are common).

What TLS gives you on port 443:

Encryption — outsiders cannot read the body or headers in transit
Integrity — tampering is detected
Authentication of the server — the certificate proves you reached the real host (when the chain of trust is valid)

Flow in words: TCP handshake first, then TLS handshake (cipher choice, certificates, keys), then HTTP inside the encrypted tunnel.

Use HTTPS for anything with login forms, cookies, or personal data.

WebSocket

WebSocket is for long-lived, two-way communication: chat, live dashboards, multiplayer games.

It does not replace TCP. The usual path:

Start with a normal HTTP or HTTPS request.
The client sends an Upgrade header asking to switch to WebSocket.
If the server agrees, the same TCP connection becomes a WebSocket.

ws:// — WebSocket over HTTP (unencrypted)
wss:// — WebSocket over HTTPS (encrypted), same idea as HTTPS

After the upgrade, both sides can push messages anytime without opening a new HTTP request for each message.

gRPC

gRPC is an application RPC framework: the client calls a method on the server as if it were a local function. Payloads are often Protocol Buffers (binary, compact), not JSON.

On the wire, gRPC commonly uses HTTP/2 over TCP (port 443 in production, often with TLS). It fits service-to-service calls inside a backend, not human-facing web pages.

Protocol	Typical use	Transport
HTTP/HTTPS	Browsers, REST APIs	TCP
WebSocket / WSS	Chat, live updates	TCP
gRPC	Microservices, internal APIs	TCP (HTTP/2)
UDP	DNS, streaming, gaming	UDP

Register and login architecture

Two boxes: client and server. The password never travels in plain HTTP, and the database never stores the raw password.

Register

client                                              server
   |---- HTTPS: username + password --------------->|
   |                    hash password on server      |
   |                    store hash in database       |
   |<---------------- success / error --------------|

Register using HTTPS only — TLS keeps the password from being read on the network.
On the server, hash the password and store it in the database — save the hash, not the password string the user typed.

Login

client                                              server
   |---- HTTPS: username + password --------------->|
   |                    hash the password string     |
   |                    compare with hash in db      |
   |<---- success if match, failed if not ----------|

Login using HTTPS only — same protection as registration.
On the server, hash the password string and check the database — use the same hash function as at register time.
If it matches, return success; otherwise return failed.

A quick map to remember

TCP — connect with SYN, SYN-ACK, ACK; reliable.
UDP — send packets; no handshake; best effort.
HTTP — request/response on TCP; encrypt with HTTPS (TLS) for secrets.
WebSocket — upgrade HTTP(S) to ws(s) for two-way streams.
gRPC — RPC over HTTP/2 and TCP, often with TLS.
Passwords — HTTPS for register and login; hash on the server; store and compare hashes in the database.

How to optimize a database, one step at a time

Tarang — Sun, 27 Sep 2026 17:49:42 +0000

How to optimize a database, one step at a time

A database gets slow for a few different reasons. The fix depends on which reason you have. Work through the steps in this order. The early steps are cheap. The later steps change how the system is built.

Use one example the whole way: a students table with ids from 1 to 1000.

1. Query optimization

Ask the database only for what you need.

If the screen shows a student's name, this is more than you need:

SELECT * FROM students WHERE id = 345;

* means every column: address, photo, notes, and columns you will not display. That extra data still has to be read and sent over the network.

SELECT student_name FROM students WHERE id = 345;

Same row. Smaller answer.

This does not make a huge table fast by itself. It removes waste. Do it before you add hardware.

2. Indexing

An index is the index at the back of a book. You do not read every page to find "replication". You look up the word and jump to the page.

Databases store many indexes as a B-tree. The tree groups ids into ranges, so a lookup walks a few branches instead of scanning every row.

                 students (1–1000)
                 /                \
            1–500                501–1000
           /     \               /       \
       1–250   251–500       501–750   751–1000
                  ^
                  student 345 lives here

To find student 345, the database does not open all 1000 rows. It goes left (1–500), then right (251–500), then reads that block.

Create an index on the column you search by:

CREATE INDEX students_id_idx ON students (id);

An index speeds up reads. It costs a little on every insert and update, because the tree must stay in order. Index the columns in your WHERE and JOIN clauses, not every column.

3. Vertical scaling

Vertical scaling means a bigger machine: more memory, more CPU, a faster disk.

It works until the next size up is too expensive, or until one machine cannot take any more. A single server still has one ceiling. When you hit it, adding RAM again does not split the work.

Use this while one machine is still comfortable. Move on when it is not.

4. Read replicas

Reads and writes do not have to hit the same machine.

MySQL is the database people usually mean with this picture. One server is the source (older docs say master). It is the only server that takes INSERT, UPDATE, and DELETE. One or more replicas (older docs say slaves) receive a copy of those changes and serve SELECT.

PostgreSQL does the same job with different names: a primary and streaming replicas (hot standbys). Amazon RDS, for both MySQL and PostgreSQL, calls the copies read replicas.

                 +-->  source / primary     (writes)
client  ---------+-->  replica              (reads)
                 +-->  replica              (reads)

Replication keeps the copies in sync. The primary writes a change to its log. Each replica applies that log. There is a short delay, called replication lag. A read right after a write can still see the old row if it lands on a replica that has not caught up.

Replicas take read load off the primary. They do not take write load. Every write still goes to one machine.

If the primary dies, a replica can be promoted to primary so the system can keep going. That is a failover, not something that happens by itself in every setup. Promote a replica only after you know how far behind it was, or you can lose the last few writes.

5. Partitioning

Partitioning splits one table inside one database. The database still lives on one server. The rows are stored in separate pieces.

Split students by section:

        +------------------+
        |  students        |
        |  section A       |
        |  section B       |
        |  section C       |
        +------------------+
           one database

A query for section B can skip A and C. A backup or a restore can target one section instead of the whole table. That is the "faster recovery" part: you move a piece, not the entire database.

The database picks the partition from the partition key (section). You still write normal SQL. The server is still one server.

6. Sharding

Sharding is the same split, moved onto different servers. Each server holds only its piece of the data.

   +-------------+          +-------------+          +-------------+
   | section A   |          | section B   |          | section C   |
   +-------------+          +-------------+          +-------------+
     server 1                 server 2                 server 3

Server 1 does not have section B. A query for a student in section C must be sent to server 3. Something in front of the servers — the application, or a proxy — has to know that rule. The column you use for the rule is the shard key. Here the shard key is section.

Replicas copy the whole database so more machines can read it. Shards divide the database so no one machine has to store all of it or take every write.

Sharding is the last step because it is the most work to operate. A question that needs section A and section B now talks to two servers. A transaction that updates two sections is no longer a normal single-database transaction. Adding server 4 means moving some sections onto it.

Do the earlier steps first. Shard when one database, even with indexes, a bigger machine, replicas, and partitions, cannot hold the data or the writes.

A short order to remember

Ask for fewer columns.
Index the columns you search.
Give the machine more memory and CPU while that is still cheap.
Send reads to replicas. Keep writes on the primary. MySQL and PostgreSQL both do this.
Partition a large table inside one database.
Shard across servers only when one database is no longer enough.

Snake and Ladder in Go

Tarang — Sat, 19 Sep 2026 17:52:33 +0000

Snake and Ladder in Go

This is a small console Snake and Ladder game in Go. Use it to see how a program can be split into a few types that each do one thing.

The board has 100 squares, plus snakes and ladders. Three coins take turns. A coin wins only when it lands on exactly 100.

roll dice → move → if over 100, stay
         → apply snake/ladder (can chain)
         → if 100, that coin wins

Solid arrow = has / uses. Dashed arrow = implements.

Read the diagram this way: Game is the teacher of the rules. Board is the map. main only builds the pieces, then asks Game to Play().

Design ideas to notice

Keep these in mind as you read the types below.

Idea	What it means here
Facade	Callers should not wire dice, coins, and jumps themselves. They talk to `Game` (`NewGame`, `Play`).
Polymorphism	A snake and a ladder are different. After a move, the rule is the same: if you are on a start, go to the end. That is why both implement `Jumps`.
Constructors	Prefer `NewBoard`, `NewDice`, `NewCoin`, `NewLadder`, `NewSnake` so creation stays in one place.
One job per type	Board stores the layout. Game runs the turns. Dice rolls. Coin is a token.
Open for a new jump	`applyJumps` should not say `if snake` / `if ladder`. A new jump type can implement the same interface.
Depend on the interface	The turn loop should know `start()` and `end()`, not the names Snake and Ladder.

The types

Walk through each type in order. Notice what it owns, and what it refuses to own.

Square

A square is a number on the board.

type Square struct {
    SquareNumber int
}

func NewSquare(squareNumber int) *Square {
    return &Square{squareNumber}
}

Dice

The die only rolls. It does not know whose turn it is.

type Dice struct {
    Sides int
}

func NewDice() *Dice {
    return &Dice{Sides: 6}
}

func (d *Dice) RollDice() int {
    return 1 + rand.IntN(6)
}

Coin

A coin is a player token: a color and a position. It does not know the rules of the game.

type Coin struct {
    CurrentPosition *Square
    Color           string
}

func NewCoin(color string) *Coin {
    return &Coin{&Square{0}, color}
}

Jump interface, Ladder, Snake

Keep snake and ladder as two structs. They mean different things. Give them a shared interface only so the game can move a coin without caring which one it hit.

type Jumps interface {
    start() *Square
    end() *Square
}

type Ladder struct {
    Start *Square
    End   *Square
}

func NewLadder(startSquare Square, endSquare Square) *Ladder {
    return &Ladder{&startSquare, &endSquare}
}

func (l *Ladder) start() *Square { return l.Start }
func (l *Ladder) end() *Square   { return l.End }

type Snake struct {
    Start *Square
    End   *Square
}

func NewSnake(startSquare Square, endSquare Square) *Snake {
    return &Snake{&startSquare, &endSquare}
}

func (s *Snake) start() *Square { return s.Start }
func (s *Snake) end() *Square   { return s.End }

Board

The board knows the squares, the snakes, the ladders, and one combined list of jumps. It does not play.

type Board struct {
    Squares []*Square
    Ladders []*Ladder
    Snakes  []*Snake
    Jumps   []Jumps
}

func NewBoard(ladders []*Ladder, snakes []*Snake) *Board {
    var squares []*Square
    for i := 1; i <= 100; i++ {
        squares = append(squares, &Square{i})
    }
    return &Board{
        Squares: squares,
        Ladders: ladders,
        Snakes:  snakes,
        Jumps:   allJumps(ladders, snakes),
    }
}

func allJumps(ladders []*Ladder, snakes []*Snake) []Jumps {
    var jumps []Jumps
    for _, ladder := range ladders {
        jumps = append(jumps, ladder)
    }
    for _, snake := range snakes {
        jumps = append(jumps, snake)
    }
    return jumps
}

Game

Game is the place for rules: whose turn, when to stop, when a coin has won.

type Game struct {
    Board *Board
    Coins []*Coin
    Dice  *Dice
}

func NewGame(board Board, coins []*Coin) *Game {
    return &Game{&board, coins, NewDice()}
}

Play() is the lesson you should read in the full source: turns, the exact-100 rule, and chained jumps. Watch the pointers. If a coin reuses the ladder’s own Square, the next roll can change the board itself.

That code is on GitHub. Clone the repo, run go run ., and follow one coin until someone reaches 100.

Entire code on GitHub

Full source — Play(), applyJumps(), main, and a sample set of snakes and ladders:

https://github.com/tarang21/snake-and-ladder

DEV Community: Tarang

A classic linked list problem: reorder the list (mental model and dry run)

Reorder the linked list

Problem

Mental model: three steps

Step 1 — Find the middle (dry run)

Odd: 1 → 2 → 3 → 4 → 5

Even: 1 → 2 → 3 → 4

Step 2 — Reverse secondll (dry run)

Step 3 — Merge (dry run)

Odd example — after step 1 and 2

Even example

Full solution (JavaScript)

What to remember

REST API methods and DNS, in one place

Two pieces of the same web

REST API methods

GET — get the data

POST — create

PUT — replace the whole resource

PATCH — replace part of the data

DELETE — delete the data

Quick comparison

DNS — Domain Name System

Side by side

Types of connections: HTTP, TLS, WebSocket, gRPC, TCP, and UDP

What are types of connections?

TCP: the three-way handshake

UDP: no handshake, no guarantee

HTTP

HTTPS: HTTP with TLS

WebSocket

gRPC

Register and login architecture

Register

Login

A quick map to remember

How to optimize a database, one step at a time

How to optimize a database, one step at a time

1. Query optimization

2. Indexing

3. Vertical scaling

4. Read replicas

5. Partitioning

6. Sharding

A short order to remember

Snake and Ladder in Go

Snake and Ladder in Go

Design ideas to notice

The types

Square

Dice

Coin

Jump interface, Ladder, Snake

Board

Game

Entire code on GitHub

Odd: `1 → 2 → 3 → 4 → 5`

Even: `1 → 2 → 3 → 4`