Most teams open Postman to hit an endpoint, check the response, and move on. Requests are named randomly, URLs are hardcoded, tokens are pasted by hand, and there isn’t a single assertion in sight.

It works - until it doesn’t. And when it breaks, no one knows what changed, what failed, or why.

This “just test it quickly” mindset turns Postman into a disposable tool instead of what it actually is: an API testing and automation platform. A scratchpad doesn’t need structure. An engineering tool does. When your Postman collection has no environments, no shared auth, no reusable scripts, and no tests, you’re not validating APIs - you’re hoping they work.

This article is about drawing a hard line: when to stop using Postman like a scratchpad, and how to start using it like an engineering tool.

Here are actually useful Postman tips.

Use Collection-level auth

If you’re copy-pasting Authorization headers into every request, your Postman collection is already broken.

Set authentication once at Collection → Authorization and let all requests inherit it automatically. Store tokens in environment variables and reference them from the collection. When the token format or auth scheme changes, you update it in one place - not twenty.

Override auth at the request level only when you truly need to. Otherwise, it’s noise and a maintenance risk.

Auth belongs to the collection, not individual requests**. (Purely depends on the module you are testing)

Never Hardcode Values : Use Environments

Hardcoding base URLs, tokens, or IDs is the fastest way to make a Postman collection brittle. The moment you switch from local to staging or production, everything breaks.

Instead, use environment variables like:

{{baseUrl}}
{{token}}
{{userId}}

Each environment (dev, staging, prod) defines its own values, while the collection stays unchanged. Switching environments then becomes a dropdown change, not a manual edit across requests.

If changing environments requires touching requests, your collection isn’t reusable - it’s fragile.

Always Add Basic Tests : Even for Manual Testing

If a request has no tests, Postman can’t tell you when something breaks - you have to notice it yourself. That doesn’t scale.

At the very least, assert the status code:

pm.test("200 OK", () => {
  pm.response.to.have.status(200);
});

This turns a manual check into an automatic guardrail. The moment an endpoint starts returning the wrong status, Postman flags it immediately. Small tests like this catch backend regressions early, long before they reach production.

For Example: You have a GET /users/{id} API. Yesterday it returned 200 OK. Today, due to a backend change, it starts returning 500 for some users.

Now the moment the API returns anything other than 200, the request fails visibly. In the Collection Runner or CI, the run stops and the regression is caught immediately.

Use Pre-request Scripts for Dynamic Data

Hardcoded values don’t survive real testing. Anything that changes per request should be generated before the request is sent.

Pre-request scripts are ideal for:

• timestamps

• nonces

• random emails / IDs

• request signatures (HMAC, hashes)

Example:

pm.environment.set("ts", Date.now());

That value can then be reused in headers, query params, or the request body. This keeps requests deterministic while still behaving like real traffic.

If your API requires freshness or uniqueness and you’re typing values manually, you’re testing unrealistically.

Use Post-Request (Tests) Scripts Properly

Post-request scripts run after the API responds. This is where real validation and chaining should happen, not manual testing.

Post scripts are used to:

• Assert status codes and response structure

• Validate business rules

• Extract values for the next request

• Fail fast when contracts break

Example: validate and extract data

pm.test("200 OK", () => {
  pm.response.to.have.status(200);
});

const res = pm.response.json();
pm.environment.set("userId", res.id);

This turns responses into inputs for the next step in the workflow. No copy-pasting. No guessing.

If your post scripts only log responses or don’t exist at all, Postman isn’t testing anything → it’s just showing you JSON.

Name Requests Like Real Workflows

Request names should tell a story, not just repeat HTTP paths.

This is unhelpful:

GET /users

This is usable:

01 - Login
02 - Create User
03 - Fetch User

Clear, ordered names make collections readable and runnable. They also matter in Collection Runner and CI, where execution order defines the workflow. If someone can’t understand the flow by scanning the request list, the collection isn’t doing its job.

Use Examples as Documentation

Postman examples are not just mock responses. Used properly, they become living documentation.

Well-maintained examples act as:

• API documentation for consumers

• A contract reference for frontend and backend teams

• An onboarding tool for new engineers

Examples show what a correct request and response look like, without reading specs or code. If examples are outdated or missing, teams guess - and guessing breaks contracts.

Treat examples as part of the API surface. Keep them accurate, review them when APIs change, and maintain them with the same discipline as code.

Import OpenAPI → Then Clean It

Importing an OpenAPI spec into Postman is a great starting point, but it should never be the final state. Auto-generated collections are always messy: cryptic request names, flat structures, no flow, and zero tests.

Treat the import as scaffolding, not a finished product.

After importing:

• Rename requests to reflect real actions

• Group related requests into meaningful flows

• Add basic tests and shared scripts

Version Control Your Postman Collections

Postman doesn’t give you real, inbuilt version control and that’s fine. You’re still expected to handle it like engineers do.

Export your collections as JSON files, keep them inside your project repository, and treat them like any other code artifact:

• Export collections as JSON

• Commit them to Git

• Review changes in pull requests

This gives you history, accountability, and team visibility. You can see when an endpoint changed, when a test was added, or when a breaking update slipped in.

Conclusion

Use Postman to encode how your APIs are supposed to behave, not just to check whether they respond. That shift → from clicking to testing → is what separates quick experiments from reliable systems.

Postman is not a scratchpad. Treat it like one, and you’ll keep shipping uncertainty. Treat it like an engineering tool, and it will start paying for itself.

So you do what everyone does: blame Redis.

Except Redis did exactly what you asked it to do.

The real bug is small and far more common in production systems: your read replicas are the culprit, and they’re lying to your cache.

In systems with async replication, clearing the cache on write is not enough. The next read can hit a lagging replica, fetch stale data, and happily re-poison Redis with it. From that point on, even after the replica catches up, your cache is already wrong.

This isn’t a Redis problem.
It isn’t a race condition.
It’s a read-after-write consistency failure caused by replica lag — and most cache-aside implementations are vulnerable to it by default.

To understand why this happens, let’s first look at an important database concept: replicas.

Replicas

Replication means copying the same data to multiple databases and having a Primary (Leader) that handles writes, and one or more Replicas (Followers) that handle reads.

All replicas contain the same data - eventually.

The Pitfall

While replicas improve read scalability and availability, they come with trade-offs:

• Writes still go to a single primary

• Replication lag is unavoidable

• Replica lag causes read-after-write inconsistency

When combined with cache invalidation, this lag can lead to stale data being re-cached, resulting in what looks like a “dirty Redis read” , even though Redis did nothing wrong.

What You Can Do

1. Read from PRIMARY after write (Read Your Writes)

After a write, route reads for that entity to the primary.
Switch back to replicas only after some time or once consistency is guaranteed.

2. Write-through cache (update cache on write)
Instead of deleting the cache:

Write to the database
Update Redis with the new value

Even if replicas lag, the cache already contains correct data, so there’s no stale repopulation.

Trade-offs:
Increased write complexity
You must ensure the DB write succeeded before updating cach

To Conclude this

Replication scales reads.
Caching speeds reads.
Correctness is your responsibility.

Once you internalize that, this entire class of bugs disappear

We’ll explore what TOTP is, how it works, and how you can implement it in your applications.

What is TOTP?

TOTP stands for Time-based One-Time Password.

It is an algorithm that generates a unique, temporary numeric code that expires after a short period of time (typically 30 seconds).

You’ve likely seen it in action when using apps like Google Authenticator, Authy, or Microsoft Authenticator. These apps generate a 6-digit (or sometimes 8-digit) code that refreshes every 30 seconds, and you need to enter it to complete login.

This makes TOTP a core building block of Two-Factor Authentication (2FA).

How TOTP Works (Step-by-Step)

At its core, TOTP is built on top of HOTP (HMAC-based One-Time Password), with time being the moving factor instead of a counter.

1. Secret Key Generation

   • When a user enables 2FA, the server generates a secret key (a random base32 string).

   • This secret is shared with the user and stored securely on the server.

   • The user scans a QR code that contains the secret, adding it to their Authenticator app.

2. Code Generation (Client-Side)

   • Every 30 seconds, the app:

     • Takes the current Unix timestamp (e.g., T = floor(current_time / 30)).

     • Combines it with the shared secret key.

     • Uses HMAC-SHA1 to compute a hash.

     • Truncates it to a 6-digit number — this is the code shown to the user.

3. Code Verification (Server-Side)

   • When the user enters the code, the server repeats the same calculation.

   • If the code matches what the server expects (for the current time window), authentication succeeds.

The beauty of TOTP is that no internet connection is needed for the authenticator app — both client and server just need synchronized clocks. This value will change every 30 seconds, so even if someone steals your password, they’d still need this code — making attacks significantly harder.

Why Use TOTP?

• Stronger Security – Passwords alone can be stolen or guessed. TOTP adds a dynamic factor.

• No Internet Required – Works offline once the secret is set.

• Widely Supported – Compatible with Google Authenticator, Authy, Microsoft Authenticator, etc.

• Easy to Implement – Libraries like Speakeasy (Node.js) or pyotp (Python) make it simple.

Implementing TOTP : Node.js example using Speakeasy:

import speakeasy from "speakeasy";
import qrcode from "qrcode";

// Generate a secret for the user
const secret = speakeasy.generateSecret({ length: 20 });
console.log("Secret:", secret.base32);

// Generate QR code to scan in Authenticator app
qrcode.toDataURL(secret.otpauth_url, (err, data_url) => {
  console.log("QR Code URL:", data_url);
});

// Verify token provided by user
const isVerified = speakeasy.totp.verify({
  secret: secret.base32,
  encoding: "base32",
  token: "123456", // User input
  window: 1 // Allows small time drift
});

console.log("Verified:", isVerified);

Best Practices for TOTP

• Keep Secrets Safe – Store them securely (e.g., encrypted in your database).

• Allow Small Time Drift – Users’ devices might be a few seconds off, allow ±1 time step.

• Offer Backup Codes – Users may lose their device; backup codes prevent lockouts.

• Educate Users – Clearly explain how to set up and use 2FA.

Conclusion

TOTP is one of the simplest and most effective ways to add a second layer of security to your application. It is stateless, offline, and easy to implement, making it ideal for modern web and mobile applications.

If you’re building any system where user accounts matter — implementing TOTP-based 2FA should be a no-brainer. It will drastically improve your security posture and build trust with your users.