DEV Community: Sai Praveen Sanapalli

CDN Explained: How Content Delivery Networks Work — A Complete Beginner's Guide

Sai Praveen Sanapalli — Wed, 12 Aug 2026 20:48:35 +0000

If you've ever wondered how websites deliver content quickly to users around the world, a Content Delivery Network (CDN) is a big part of the answer.

But how does a CDN actually work? How does it route users to nearby servers, cache content, and reduce the load on the origin server?

This post breaks down what a CDN actually is, how it works under the hood, its architecture, real-world examples, and why modern websites rely on CDNs.

What is a CDN?
Why Is a CDN Needed?
How Does a CDN Work?
CDN Architecture
Key Components of a CDN
What Content Does a CDN Deliver?
CDN for JavaScript, APIs, and Dynamic Websites
Caching Strategies
Real-World Examples
Popular CDN Providers
Benefits of Using a CDN
Challenges and Limitations
When Should You Use a CDN?
How to Check Which CDN a Site Uses
Summary

What is a CDN?

A Content Delivery Network (CDN) is a globally distributed network of servers that delivers content to users from a location close to them, instead of routing every request to a single origin server.

Instead of every user request traveling all the way to your origin server (the main server hosting your website), a CDN stores cached copies of your content on servers spread across the world — called edge servers or Points of Presence (PoPs).

Almost every large website today uses some form of CDN to improve performance, reduce origin-server load, handle traffic spikes, and provide additional security.

Without CDN:  User (India) → Origin Server (USA)
With CDN:     User (India) → CDN Edge (near India) → Origin (only if needed)

Why CDN is Needed

Imagine your app is hosted on a single server in Mumbai, and users come from Hyderabad, Delhi, London, New York, and Tokyo. Every single request — no matter where it originates — has to travel all the way to Mumbai and back.

Hyderabad ─┐
Delhi ─────┤
London ────┼──→ Mumbai Origin
New York ──┤
Tokyo ─────┘

The farther a user is from the origin, the more latency (network delay) is introduced. A CDN's job is to place cacheable content closer to users so this round trip shrinks dramatically.

How a CDN Works (Step by Step)

Let's trace a real request for https://example.com/logo.png from start to finish.

1. DNS Resolution

The user enters a URL such as:

https://example.com/logo.png

The browser performs a DNS lookup for example.com. If the website uses a CDN, DNS directs the request toward the CDN network rather than sending it directly to the origin server.

2. User Request Reaches the CDN

The request travels from the user's device through their ISP (such as Airtel, Jio, ACT, BSNL) and across the internet toward a suitable CDN Point of Presence (PoP).

CDNs use technologies such as Anycast routing or GeoDNS to route users to an appropriate edge location — often one that is geographically or network-wise close to them.

3. Edge Server Checks the Cache

Once the request reaches the CDN edge server, the CDN checks whether the requested content — /logo.png in this case — is already cached. There are two possible outcomes:

Cache Hit — if /logo.png is already available in the edge cache, the CDN immediately returns it to the user.

Cache Miss — if the content is not available in the edge cache, the CDN sends a request to the origin server.

4. CDN Fetches Content from the Origin

The origin server is the actual server where the website's content is stored.

User
  ↓
ISP
  ↓
CDN Edge Server
  ↓
Origin Server

The origin server returns logo.png to the CDN edge server.

5. CDN Caches the Content

The CDN stores the returned content in its edge cache according to the configured cache rules and TTL (Time to Live). The response is then sent to the user.

Origin Server
      ↓
CDN Edge Server
      ↓
    User

6. Subsequent Requests

When another user requests the same logo.png and is routed to an edge location that already has the object cached, the CDN can serve it directly:

User
  ↓
ISP
  ↓
CDN Edge
  ↓
Cached logo.png
  ↓
User

The origin server does not need to be contacted for every request.

7. Cache Expiration

Cached content has a TTL that determines how long the CDN should consider the cached object fresh. Once the TTL expires, the CDN may need to contact the origin server again to obtain a fresh version, depending on the CDN's caching and revalidation configuration.

CDN Architecture

                        USERS
                          |
                          v
                         DNS
                          |
                          v
                         ISP
                          |
                          v
                 CDN / EDGE LOCATION
                          |
                   Cache Hit?
                    /         \
                 Yes            No
                  |              |
                  v              v
                USER          ORIGIN
                                 |
                                 v
                          LOAD BALANCER
                                 |
                        +--------+--------+
                        |                 |
                   APP SERVER        APP SERVER
                        |                 |
                        +--------+--------+
                                 |
                              DATABASE

If you remember only one diagram from this whole post, remember this one — it's the backbone of every CDN explanation.

Key Components of a CDN

It helps to know the individual pieces that make up a CDN and work together on every request.

a. Origin Server

The original source of truth — where your actual website/app files live.

b. Edge Servers (PoPs — Points of Presence)

Servers distributed across multiple geographic locations that cache and serve content to nearby users.

c. DNS Routing / Anycast

Determines which edge server should handle a given user's request — usually the geographically nearest or least congested one.

d. Cache Layer

Stores static (and sometimes dynamic) content temporarily so it doesn't need to be re-fetched from the origin every time.

e. Load Balancer

Distributes incoming traffic across multiple servers to prevent overload and ensure high availability.

f. Origin Shield

An additional caching layer between edge servers and the origin, reducing the number of direct requests that hit your origin server.

What Content a CDN Delivers

A CDN isn't just for JavaScript files. It commonly handles:

Static content: images, CSS, JavaScript, fonts, PDFs
Dynamic content: personalized pages, API responses (via dynamic content acceleration)
Streaming media: video/audio (YouTube, Netflix use CDNs heavily)
Software downloads: large files like game updates, installers
Web applications: full websites via edge computing (e.g., Cloudflare Workers, Vercel Edge Functions)

CDN for JavaScript, APIs, and Dynamic Websites

CDN for JavaScript

This is where the term "JavaScript CDN" often causes confusion.

Consider Bootstrap. Instead of hosting it yourself:

<script src="/assets/bootstrap.js"></script>

you can load it from a CDN instead:

<script src="https://cdn.example.com/bootstrap.js"></script>

The JavaScript file is hosted and distributed through the CDN provider's infrastructure. Popular libraries are commonly distributed this way — jQuery, React, Bootstrap, and countless others are all available via public CDNs like jsDelivr or cdnjs.

It's worth being precise about what's actually happening here: the CDN is not "executing" your JavaScript. It is simply delivering the JavaScript file to the browser — the browser is the one that executes it. The CDN's job ends the moment the file is handed off.

CDN for APIs

A common myth is that CDNs only work for static sites. Not true — CDNs can also sit in front of APIs.

A CDN can route static assets to cache while sending dynamic requests straight to the origin:

                    CDN
                     |
          +----------+----------+
          |                     |
    Static files          Dynamic requests
   (/assets/*.js)          (/api/login)
          |                     |
          v                     v
        Cache                Origin

Take an endpoint like /api/products. Suppose the product list only changes every 5 minutes — you might configure:

Cache-Control: public, max-age=300

Now many users can be served the cached response instead of hitting your backend on every single request.

But this should only be done when serving a cached response is actually safe — meaning the response is identical for everyone requesting it. Never blindly cache personalized API responses like /api/profile, /api/cart, or /api/orders; doing so risks leaking one user's data to another.

Caching Strategies

CDNs use different caching strategies depending on the content type:

Strategy	Description	Example Use Case
Pull CDN	Content is cached only after the first user request	Blogs, general websites
Push CDN	You manually upload content to the CDN in advance	Large media files, software releases
Time-based expiry (TTL)	Content is cached for a fixed duration	Static assets like logos
Cache invalidation/purge	Manually clearing cache when content updates	After a website deployment
Stale-while-revalidate	Serves old cached content while fetching a fresh copy in background	News sites, high-traffic pages

Cache Hit vs Cache Miss

Cache hit — the requested content already exists at the edge, so it's returned immediately with no origin involved.

Cache miss — the content isn't cached yet, so the edge server fetches it from the origin (or another cache tier), caches it, and then serves it — meaning the next request for that same object is likely to be a hit.

TTL, Cache Invalidation, and Cache Busting

TTL (Time to Live) controls how long an object stays cached before it's considered stale and needs to be refreshed from the origin.

Cache invalidation / purging lets you manually clear a cached object — useful right after deploying a new version of a file the CDN is still serving an old copy of.

Cache busting is a common alternative: changing the filename whenever content changes (e.g. app.a82f91.js → app.91bc72.js) so the CDN and browser treat it as a brand-new resource, avoiding stale-cache issues entirely.

Browser Cache vs CDN Cache

These are two separate caching layers that work together:

Browser Cache               CDN Cache
└── lives on the user's     └── lives across CDN edge
    own device                  locations worldwide

If the browser already has a resource cached locally, it may skip the network entirely. If it does need to fetch it, that request then hits the CDN cache layer next — before ever reaching your origin.

DNS Alone Is Not a CDN

A common misunderstanding: pointing example.com → 1.2.3.4 in DNS does not create a CDN. DNS only tells clients where/how to reach a service — you still need an actual distributed CDN network behind that configuration. Typically your domain is set up with a CNAME (or provider-specific equivalent) pointing to a CDN-provided hostname, e.g.:

www.example.com  →  d123example.cloudfront.net

Real-World Examples

Netflix: Uses its own CDN (Open Connect) to cache movies/shows on servers close to ISPs, ensuring smooth streaming without buffering.
E-commerce sites (Amazon, Flipkart): Serve product images and static assets via CDN so pages load fast during high-traffic sales events.
News websites: Use CDNs to handle massive traffic spikes when breaking news goes viral, without crashing the origin server.
GitHub: Uses a CDN (jsDelivr, Fastly) to serve raw files and package assets globally.
Gaming platforms: Use CDNs to distribute large game updates/patches quickly to millions of users worldwide.

Popular CDN Providers

Cloudflare — widely used, offers free tier, strong security features (DDoS protection, WAF)
Akamai — one of the oldest and largest CDN providers, used by enterprises
Amazon CloudFront — integrated with AWS services
Fastly — known for real-time purging and developer-friendly edge computing
Google Cloud CDN — integrated with Google Cloud Platform
jsDelivr — popular free CDN for open-source JS/CSS libraries and npm packages

Benefits of Using a CDN

Faster load times — content served from nearby edge servers
Reduced origin server load — fewer direct requests hit your main server
Improved scalability — handles traffic spikes gracefully
Better reliability/uptime — if one edge server fails, traffic reroutes to another
Enhanced security — many CDNs offer DDoS protection, bot mitigation, and SSL/TLS termination
SEO benefits — page speed is a ranking factor for search engines
Bandwidth cost savings — cached content reduces data transfer from the origin

Challenges and Limitations

Cache invalidation complexity — ensuring users don't see stale/outdated content
Cost — can get expensive at very high traffic volumes
Dynamic content limitations — not all CDNs handle personalized/dynamic content well
Debugging difficulty — issues can be harder to trace since content isn't always coming from your origin
Vendor lock-in — switching CDN providers can require configuration changes

When Should You Use a CDN?

You should seriously consider a CDN if:

Your website/app has users spread across different geographic regions
You serve a lot of static assets (images, videos, JS/CSS bundles)
You expect high or unpredictable traffic (product launches, sales, viral content)
You want to improve page speed/SEO performance
You need extra protection against DDoS attacks

Even small projects and personal blogs benefit from free-tier CDNs like Cloudflare.

Less critical for:

- Small internal tools
- Very low traffic
- Purely private/dynamic requests
- Users concentrated right next to the origin

How to Check Which CDN a Site Uses

Browser DevTools: open Network tab, reload the page, inspect a resource's response headers. Cloudflare, for example, often exposes headers like cf-cache-status and server: cloudflare; other providers have their own signatures.

curl:

curl -I https://example.com

Look for headers like cache-control, age, and server.

DNS lookup:

dig example.com

A CNAME pointing to something like *.cloudfront.net is a strong clue about which CDN is in use.

Note: the exact physical data center a request was served from usually isn't discoverable from public headers — CDN routing is dynamic, and providers generally don't expose exact building/server-level detail.

Summary

A CDN is a globally distributed network of servers that sits between your users and your origin server, caching and delivering content from the location closest to each user — instead of routing every request across the world to a single origin.

The core flow to remember:

User → DNS → ISP → CDN Edge Location → Cache Hit/Miss → Origin (if needed)

On a cache hit, the edge server answers directly. On a cache miss, it fetches from the origin, caches the response according to its TTL, and serves future requests from cache — until that TTL expires or the content is invalidated.

What makes this work, pulled from the post:

Components — origin server, edge servers/PoPs, DNS/Anycast routing, cache layer, load balancer, and origin shield all work together on every request.
What gets delivered — not just JavaScript: images, CSS, fonts, video, downloads, and even API responses and full dynamic apps via edge computing.
Caching strategies — pull vs push CDNs, TTL-based expiry, manual invalidation/purging, and cache busting (renaming files) all exist to balance freshness against performance.
Not just static sites — CDNs can safely accelerate APIs too, as long as cacheable responses are the same for every user; personalized endpoints should never be cached this way.
DNS alone isn't a CDN — you need an actual distributed CDN network behind your domain, not just a DNS record. Why it matters: faster load times, less load on your origin, better resilience during traffic spikes, built-in DDoS/WAF protection from most providers, and a real SEO benefit since page speed affects ranking. The trade-offs are mainly cache-invalidation complexity, cost at scale, and slightly harder debugging.

If you're building anything with users spread across regions, or expecting unpredictable traffic, a CDN isn't optional anymore — it's a baseline part of modern web architecture, and even a free tier (like Cloudflare) is worth adding to a small project.

Have you set up a CDN for one of your own projects? Drop the provider you used (and what tripped you up) in the comments — I'd love to hear it.

PostgreSQL Replication: The Complete Guide to Read Replicas, Architecture, and Setup

Sai Praveen Sanapalli — Tue, 11 Aug 2026 18:22:49 +0000

Replication is one of those topics that every backend engineer eventually has to deal with — usually right when the primary database starts sweating under load, or right after an outage nobody wants to repeat. This guide walks through everything you need to know about PostgreSQL replication: what it is, why you need it, how it actually works under the hood, and how to configure it yourself, step by step.

What Is a Read Replica?
Why Read Replicas Are Needed
Primary vs Replica: Key Differences
How Replication Works
Replication Flow
Synchronous, Asynchronous & Semi-Synchronous Replication
Replication Lag & Monitoring
Types of Replication in PostgreSQL
PostgreSQL Replication Architecture
Replication Components — Detailed Breakdown
Checking PostgreSQL Activity and Storage
Primary Server Configuration
Replica Server Configuration
Setting Up a Replica (Local & Remote)
Verifying and Testing Replication
Summary

What Is a Read Replica?

A read replica is a live, continuously-updated copy of your primary PostgreSQL database that accepts read-only queries. It is not a static backup — it stays in near real-time sync with the primary by receiving and replaying the stream of changes the primary produces.

Any attempt to run INSERT, UPDATE, or DELETE on a replica will fail with an error like:

ERROR: cannot execute INSERT in a read-only transaction

This is by design. The replica exists purely to serve reads, while all writes continue to go through the primary.

Why Read Replicas Are Needed

As an application grows, a single database instance becomes a bottleneck and a single point of failure. Read replicas solve several real problems at once:

Read/write separation – offload SELECT-heavy traffic away from the primary so writes aren't competing for resources.
High availability & failover – a replica can be promoted to primary if the original server goes down.
Backup offloading – run pg_dump or backup jobs against a replica instead of hammering the primary.
Real-time reporting/analytics – dashboards and BI tools can query a replica without impacting production traffic.
Geographic distribution – place replicas closer to users in different regions to reduce read latency.

Primary vs Replica: Key Differences

Aspect	Primary Server	Replica Server
Writes (`INSERT`/`UPDATE`/`DELETE`)	Allowed	Blocked (read-only)
Reads (`SELECT`)	Allowed	Allowed
Generates WAL	Yes	No — it receives WAL
Role	Source of truth	Follower, replays changes
`pg_is_in_recovery()`	Returns `false`	Returns `true`
Config flag	Normal instance	`hot_standby = on`, has `standby.signal`
Can be promoted	N/A	Can be promoted to primary during failover

How Replication Works

Every change made to a PostgreSQL database — an insert, update, delete, or schema change — is first written to the Write-Ahead Log (WAL) before it's applied to the actual data files. This is a core durability mechanism in PostgreSQL, and replication piggybacks directly on it.

In physical replication:

The primary writes every change as a WAL record.
A WAL sender process on the primary streams these WAL records to the replica.
A WAL receiver process on the replica receives the records and writes them to its own WAL.
The startup process on the replica continuously replays the WAL, applying the same changes to its local data files.
The replica's data converges to match the primary, typically within milliseconds to seconds.

Because the replica is replaying the exact same WAL as the primary, it ends up as a faithful copy — including indexes, table structures, and data.

Replication Flow

A simplified view of the data flow:

Client Write Request
        |
        v
  Primary Server  --> WAL Generated --> WAL Sender Process
        |                                      |
        |                              (streams over network)
        |                                      v
        |                              WAL Receiver Process (Replica)
        |                                      |
        |                                      v
        |                              Replica WAL written locally
        |                                      |
        |                                      v
        |                         Startup Process replays WAL
        |                                      |
        |                                      v
        |                         Replica data files updated
        v
  Client Read Request ----------> Can be served by Primary OR Replica

Synchronous, Asynchronous & Semi-Synchronous Replication

PostgreSQL supports three modes that control how strictly the primary waits for a replica before confirming a write:

Asynchronous Replication (default)

The primary commits a transaction and returns success to the client immediately, without waiting for the replica to confirm it received or applied the WAL. This is fast, but there's a small risk: if the primary crashes right after commit, the very latest transactions might not have reached the replica yet.

Synchronous Replication

The primary waits for at least one designated synchronous standby to confirm it has received (and optionally flushed) the WAL before acknowledging the commit to the client. This guarantees zero data loss for that transaction but adds latency, since every commit is gated on network round-trip time to the replica.

Configured via:

synchronous_standby_names = 'replica1'
synchronous_commit = on

Semi-Synchronous Replication

A middle ground: the primary waits for confirmation that the WAL has been received by at least one replica (not necessarily applied/flushed to disk), balancing durability and performance. PostgreSQL's synchronous_commit parameter has several levels (remote_write, remote_apply, on, local, off) that let you fine-tune exactly how much guarantee you want versus how much latency you're willing to accept.

Mode	Data Loss Risk	Write Latency	Use Case
Asynchronous	Small window possible	Lowest	Reporting replicas, general read scaling
Semi-synchronous	Very low	Moderate	Balanced HA setups
Synchronous	None (for that replica)	Highest	Financial/critical systems requiring zero data loss

Replication Lag & Monitoring

Replication lag is the delay between a change happening on the primary and that same change being visible on the replica. Some lag is normal and expected in asynchronous replication — the goal is to keep it small and to catch it if it grows.

Check connected replicas (run on primary)

SELECT pid, client_addr, state, sync_state, write_lag, flush_lag, replay_lag
FROM pg_stat_replication;

Count active replicas

SELECT count(*) FROM pg_stat_replication;

Check replication lag in time (run on replica)

SELECT now() - pg_last_xact_replay_timestamp() AS replication_lag;

Check replication slots

SELECT slot_name, slot_type, active FROM pg_replication_slots;

Check WAL retained per slot

SELECT slot_name,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS wal_retained
FROM pg_replication_slots;

Check WAL directory size

SELECT pg_size_pretty(sum(size)) FROM pg_ls_waldir();

Check WAL receiver status (run on replica)

SELECT * FROM pg_stat_wal_receiver;

Why monitoring matters: if a replica falls too far behind and its replication slot retains too much WAL, the primary's disk can fill up. Persistent high lag is usually a sign of network issues, an underpowered replica, or heavy write volume outpacing the replica's replay speed.

Types of Replication in PostgreSQL

PostgreSQL supports a few distinct approaches, each suited to different needs:

Method	Type	Notes
Streaming replication	Physical	Real-time binary replication of the WAL. The replica is a byte-for-byte copy of the primary. Most common choice for standard read replicas — simple, reliable, keeps the whole database in sync automatically.
Logical replication	Logical	Table-level replication of data changes via logical decoding of WAL. Enables selective replication, cross-version replication, and CDC pipelines (Debezium, Kafka).
WAL file shipping	Physical	Periodic shipping of completed WAL segments instead of continuous streaming — an older, higher-lag, file-based approach still seen in some legacy setups.
Cascading replication	Physical	Replicas stream WAL to other replicas instead of all pulling from the primary directly — reduces load on the primary when many replicas are needed.

PostgreSQL Replication Architecture

A typical production architecture looks like this:

                 +--------------------+
                 |   Primary Server   |
                 |   (Read + Write)   |
                 +---------+----------+
                            | WAL Streaming
        +-------------------+-------------------+
        v                   v                   v
 +--------------+   +--------------+   +--------------+
 | Read Replica |   | Read Replica |   | Read Replica |
 |      1       |   |      2       |   |      3       |
 | (Read only)  |   | (Read only)  |   | (Read only)  |
 +--------------+   +--------------+   +--------------+

Reads get distributed across replicas (often via a load balancer, connection pooler like PgBouncer, or application-level routing), while all writes are funneled to the single primary.

Replication Components — Detailed Description

Component	Description
WAL (Write-Ahead Log)	Sequential log of every change made to the database, written before the change is applied to data files. Forms the basis of both crash recovery and replication.
WAL Sender	A process on the primary, spawned per connected replica, that reads WAL and streams it over the network.
WAL Receiver	A process on the replica that receives streamed WAL from the primary and writes it locally.
Startup Process (Replay)	On the replica, continuously reads the locally-written WAL and applies (replays) the changes to data files.
Replication Slot	A primary-side bookmark that ensures WAL isn't removed until the corresponding replica has consumed it — prevents replicas from falling irrecoverably behind, but can cause disk bloat if a replica disconnects for a long time.
`pg_stat_replication`	A system view on the primary showing real-time status of every connected replica (lag, state, sync mode).
`standby.signal`	A marker file in the replica's data directory indicating it should start in standby (replica) mode.
`hot_standby`	A setting that allows the replica to serve read-only queries while it's replaying WAL, instead of being completely inaccessible.
`pg_basebackup`	The utility used to take a full physical copy of the primary's data directory as the starting point for a new replica.
Replication User	A dedicated PostgreSQL role with the `REPLICATION` privilege used exclusively for streaming WAL — never for application queries.

Checking PostgreSQL Activity and Storage

Before setting up replication, it's good practice to understand your primary's current load and size.

Connections and active queries

SELECT count(*) FROM pg_stat_activity;

SELECT usename, application_name, count(*)
FROM pg_stat_activity
GROUP BY usename, application_name;

SELECT pid, usename, state, query
FROM pg_stat_activity
WHERE state = 'active';

SHOW max_connections;

SELECT state, count(*) FROM pg_stat_activity GROUP BY state;
SELECT datname, count(*) FROM pg_stat_activity GROUP BY datname;
SELECT usename, count(*) FROM pg_stat_activity GROUP BY usename;

Database size

SELECT datname AS database_name,
       pg_size_pretty(pg_database_size(datname)) AS size
FROM pg_database
ORDER BY pg_database_size(datname) DESC;

Top 20 largest tables

SELECT schemaname,
       relname AS table_name,
       pg_size_pretty(pg_total_relation_size(relid)) AS total_size,
       pg_size_pretty(pg_relation_size(relid)) AS table_size,
       pg_size_pretty(pg_indexes_size(relid)) AS index_size
FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC
LIMIT 20;

Primary Server Configuration

1. Locate the configuration file

Ubuntu (PostgreSQL 14): /etc/postgresql/14/main/postgresql.conf
Mac (Homebrew, PostgreSQL 14): /opt/homebrew/var/postgresql@14/postgresql.conf
Ubuntu (PostgreSQL 15): /etc/postgresql/15/main/postgresql.conf

2. Check current replication-related settings

SHOW wal_level;
SHOW max_wal_senders;
SHOW wal_keep_size;
SHOW max_replication_slots;

SELECT name, setting
FROM pg_settings
WHERE name LIKE '%wal%' OR name LIKE '%replication%';

3. Update `postgresql.conf`

wal_level = replica
max_wal_senders = 10
max_replication_slots = 10
wal_keep_size = 1GB

wal_level = replica enables enough WAL detail for streaming replication.
max_wal_senders caps how many replicas can connect simultaneously.
max_replication_slots caps how many replication slots can exist.
wal_keep_size keeps a buffer of WAL on disk so a temporarily disconnected replica can catch up.

4. Configure `pg_hba.conf` to allow replica connections

Local testing:

host    replication     replicator      127.0.0.1/32            md5

host    replication     all             127.0.0.1/32            scram-sha-256

Remote replica (example IP 192.168.1.50):

host    replication     replicator      192.168.1.50/32         md5

5. Reload / restart PostgreSQL

sudo systemctl restart postgresql

SELECT pg_reload_conf();

6. Create the replication user

SELECT rolname, rolreplication, rolcanlogin FROM pg_roles;

CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD 'your_secure_password';

Permission	Meaning
`LOGIN`	Can connect to the database
`REPLICATION`	Can stream WAL files

Replica Server Configuration

Enable hot standby mode so the replica can serve read queries while replaying WAL:

hot_standby = on

Also confirm a standby.signal file exists in the replica's data directory — this is what tells PostgreSQL to start the instance as a standby rather than a primary. pg_basebackup with the -R flag creates this automatically.

Setting Up a Replica (Local & Remote)

Local Replica (Same Server)

# Create data directory
mkdir ~/pg_replica
chmod 700 ~/pg_replica

# Take a base backup from the primary
pg_basebackup -h 127.0.0.1 -D ~/pg_replica -U replicator -P -R

# Change the replica's port to avoid conflicts
nano ~/pg_replica/postgresql.conf
port = 5433
hot_standby = on

# Start the replica
pg_ctl -D ~/pg_replica start

# Stop the replica
pg_ctl -D ~/pg_replica stop

Remote Replica (Different Server)

Make sure the primary allows remote replication (pg_hba.conf entry + firewall port 5432 open).

# On the replica server
mkdir ~/pg_replica
chmod 700 ~/pg_replica

# Base backup from the remote primary
pg_basebackup -h <PRIMARY_IP> -D ~/pg_replica -U replicator -P -R

# Configure postgresql.conf
port = 5432
hot_standby = on

# Start the replica
pg_ctl -D ~/pg_replica start

Tip: If pg_ctl: command not found, locate your PostgreSQL binaries with:
which psql
sudo find / -name pg_ctl 2>/dev/null
Typical path: /usr/lib/postgresql/14/bin/pg_ctl

Verifying and Testing Replication

On the primary — confirm the replica is connected

SELECT * FROM pg_stat_replication;

On the replica — confirm it's in recovery (standby) mode

SELECT pg_is_in_recovery();  -- should return true

Test that writes are blocked on the replica

INSERT INTO replication_test VALUES (2, 'test');
-- ERROR: cannot execute INSERT in a read-only transaction

Test that data actually replicates

On primary:

INSERT INTO test_table VALUES (1, 'test');

On replica:

SELECT * FROM test_table;
-- The row should appear here almost immediately

Summary

A read replica is a live, read-only copy of your primary database kept in sync via WAL.
Replication exists to scale reads, enable high availability, offload backups, and support real-time reporting.
PostgreSQL supports physical (streaming), logical, and WAL file-shipping replication.
Replication can run in asynchronous, synchronous, or semi-synchronous modes, trading off latency against durability guarantees.
Core components — WAL, WAL sender/receiver, replication slots, and the startup/replay process — work together to keep replicas in sync.
pg_stat_replication, pg_stat_wal_receiver, and pg_replication_slots are your primary tools for monitoring health and lag.
Setup is largely the same across PostgreSQL 14 and 15, on Ubuntu or macOS, for local or remote replicas: configure the primary (wal_level, max_wal_senders, pg_hba.conf, replication role), configure the replica (hot_standby, standby.signal), take a base backup with pg_basebackup -R, and verify with pg_stat_replication / pg_is_in_recovery().

Replication is foundational to running PostgreSQL reliably at scale — once you understand the WAL-driven mechanics behind it, the rest (sync modes, monitoring, failover) all falls into place naturally.

40+ Best Chrome Extensions Every Developer Should Know in 2026

Sai Praveen Sanapalli — Fri, 31 Jul 2026 15:58:53 +0000

If you're a developer, your browser is basically your second IDE. The right set of Chrome extensions can save you hours every week — from debugging React state to picking the perfect hex code to testing APIs without leaving the tab.

I put together this list of the extensions I rely on (and a few community favorites), organized by category, with a quick description of what each one actually does.

Frontend Development & UI Design

Extension	Description
React Developer Tools	Inspect the React component tree, view props/state in real time, and profile render performance. A must-have for any React project.
Vue.js Devtools	The Vue equivalent of React DevTools — inspect components, Vuex/Pinia state, events, and routing.
Angular DevTools	Debug Angular apps by exploring the component tree, checking change detection, and profiling performance.
Redux DevTools	Time-travel through Redux state changes, inspect dispatched actions, and debug your app's state management.
Wappalyzer	Instantly detect what technologies a website is built with — frameworks, CMS, analytics tools, hosting, and more.
WhatFont	Click any text on a page to instantly see its font family, size, weight, and color.
ColorZilla	An advanced color picker and eyedropper with gradient generator and CSS color analysis tools.
VisBug	An open-source design tool that lets you edit any live webpage's layout, spacing, and typography directly in the browser.
Dimensions	Measure distances, padding, and margins on any webpage by hovering over elements.
SVG Gobbler	Find, extract, and export every SVG, icon, and image on a page in one click.
CSS Viewer	See the computed CSS styles of any element just by clicking on it.
Eye Dropper	A simple, fast color picker that grabs the exact hex/RGB value of any pixel on your screen.
Window Resizer	Quickly resize your browser window to test responsive designs at common device resolutions.
Page Ruler	Draw a ruler over any part of a webpage to measure exact pixel dimensions.

API Development & Testing

Extension	Description
Postman Interceptor	Captures browser requests (including cookies) and syncs them into Postman for accurate API testing.
Talend API Tester	A lightweight tool for sending REST/SOAP requests and inspecting responses without leaving Chrome.
Requestly	Intercept, modify, redirect, and mock HTTP requests — great for testing edge cases and API mocking.
RESTED	A minimalist REST client for quickly firing off API requests and viewing formatted responses.
WebSocket DevTools	Monitor and debug WebSocket connections and messages in real time.
GraphQL Network Inspector	Inspect GraphQL queries, mutations, and responses directly in your browser's dev tools panel.
Swagger Viewer	Render and preview OpenAPI/Swagger specs as interactive, readable documentation.
JSON Formatter	Automatically pretty-prints raw JSON responses in the browser, making them readable and collapsible.
Fake Filler	Auto-fills forms with realistic dummy data — handy for quickly testing form validation and flows.
Mobile Simulator	Emulate different mobile devices and screen sizes to test responsive and mobile-first designs.

Debugging & Performance

Extension	Description
Lighthouse	Google's built-in auditing tool for performance, accessibility, SEO, and best practices scoring.
Web Vitals	Displays Core Web Vitals (LCP, FID/INP, CLS) for any page you visit, in real time.
Reactime	A time-travel debugger for React that visualizes state changes and component re-renders over time.

Screen Capture & Recording

Extension	Description
Screenity	A free, open-source screen recorder with annotation tools, webcam overlay, and no watermarks.
GoFullPage	Capture a full-page screenshot of any website in one click, including content below the fold.
Loom	Record quick video walkthroughs of your screen and camera — great for bug reports and async updates.

🚀 Productivity & Workflow

Extension	Description
OneTab	Convert all your open tabs into a single list to save memory and declutter your browser instantly.
Session Buddy	Save, organize, and restore groups of browser tabs and sessions whenever you need them.
Workona	A tab and workspace manager that organizes tabs into projects for better focus.
Raindrop.io	A powerful bookmark manager with tags, collections, and full-text search for saved links.
Todoist	Manage your to-do lists and tasks directly from the browser toolbar.
Clockify	Track time spent on tasks and projects right from your browser.
Momentum	Replaces your new tab page with a personal dashboard featuring goals, to-dos, and inspiration.
Grammarly	AI-powered writing assistant that checks grammar, tone, and clarity as you type — including in code comments and docs.
Muzli	A curated feed of design inspiration, articles, and trends shown on your new tab page.
Octotree	Adds a file-tree sidebar to GitHub repositories for easier code navigation.
Toby	Organize and share collections of tabs across projects and teams.
Perplexity	An AI-powered search assistant that gives sourced, conversational answers directly in your browser.
Monica AI	An all-in-one AI copilot for chat, writing, summarization, and translation while browsing.
Sider AI	A sidebar AI assistant that summarizes pages, chats with PDFs, and helps with writing across any site.

Final Thoughts

You don't need all 40+ of these installed at once — that'll just slow your browser down. Pick a handful from each category based on your actual stack and workflow.

What extensions made your list that aren't here? Drop them in the comments 👇

AWS Fundamentals to Services: A Beginner's Guide to Global Infrastructure and Core Services

Sai Praveen Sanapalli — Thu, 30 Jul 2026 17:20:48 +0000

If you're starting your cloud journey, AWS can feel overwhelming — 200+ services, cryptic acronyms, and a global footprint spanning dozens of regions. This guide breaks it down into three digestible parts:

AWS Global Infrastructure — the foundation
AWS Service Categories — the building blocks
What beginners should learn first — and in what order

Let's dive in.

1. AWS Global Infrastructure — The Foundation

Before touching a single service, it's worth understanding where AWS actually runs. Everything sits on top of three core concepts: Regions, Availability Zones, and Edge Locations.

🌍 What is an AWS Region?

A Region is a physical geographic location where AWS operates multiple data centers.

Use cases:

✅ Deploy applications closer to users for lower latency
✅ Meet data residency and compliance requirements
✅ Disaster recovery across regions
✅ Global application deployment

🏢 What is an Availability Zone (AZ)?

An Availability Zone is one or more isolated data centers within a Region. Each AZ has:

⚡ Independent Power
❄️ Independent Cooling
🔗 Independent Networking
🔒 High-speed Private Links

Example — Mumbai Region (ap-south-1):

AZ-A  <——>  AZ-B  <——>  AZ-C

Use cases:

✅ High Availability
✅ Fault Tolerance
✅ Business Continuity
✅ Production Workloads

A common pattern: a Load Balancer sits in front of EC2 instances spread across AZ-A and AZ-B.

💡 If one AZ fails, your application keeps running in another AZ.

🌐 What are Edge Locations?

Edge Locations are AWS Points of Presence used by CDN and networking services — mainly powering:

Amazon CloudFront
AWS Global Accelerator

Use cases:

✅ Faster content delivery
✅ Reduced latency
✅ Global caching

Example: A website hosted in the Mumbai Region is accessed by users from Hyderabad, Chennai, Singapore, and London. CloudFront caches content at the nearest edge location instead of fetching every request all the way back to Mumbai.

📊 AWS Global Infrastructure by the Numbers (2024)

Metric	Count
🌐 Regions	39
🏢 Availability Zones	123
📡 Edge Locations & Points of Presence	700+

2. AWS Service Categories & Main Services

AWS has 200+ services, but they cluster into a manageable set of categories. Here's the map:

Category	Key Services
🖥️ Compute	EC2, Lambda, ECS, EKS, Fargate, Elastic Beanstalk
💾 Storage	S3, EBS, EFS, FSx, AWS Backup
🗄️ Database	RDS, Aurora, DynamoDB, ElastiCache, Redshift
🌐 Networking & CDN	VPC, Route 53, ELB, CloudFront, Transit Gateway
🔐 Security & Identity	IAM, KMS, Secrets Manager, WAF, Shield, GuardDuty
📩 Notifications & Messaging	SES, SNS, SQS, EventBridge
📈 Monitoring & Observability	CloudWatch, CloudTrail, AWS Config, X-Ray
⚙️ Automation & Serverless	Lambda, Systems Manager, Step Functions, EventBridge
🔁 DevOps & CI/CD	CodeCommit, CodeBuild, CodeDeploy, CodePipeline, CloudFormation
🧠 AI / ML & Generative AI	SageMaker, Bedrock, Rekognition, Textract, Comprehend
📊 Analytics & Big Data	Athena, Glue, EMR, Kinesis, QuickSight
☁️ Migration & Hybrid Cloud	DMS, Application Migration Service (MGN), DataSync, Storage Gateway
🏛️ Management & Governance	Organizations, Control Tower, Trusted Advisor, Service Catalog
🔍 Search & Integration	OpenSearch Service, API Gateway, AppSync
🛡️ Disaster Recovery & Backup	AWS Backup, Elastic Disaster Recovery (DRS), S3 Glacier

Yes, this list can feel like alphabet soup at first — but notice how each category maps to a real-world engineering need: run code, store data, secure access, monitor systems, automate ops, and so on.

3. AWS Services Every Beginner Should Learn First

Instead of trying to learn everything at once, focus on this core set:

🔒 IAM – Identity & Access Management
🖥️ EC2 – Virtual Servers
🪣 S3 – Object Storage
🌐 VPC – Networking Foundation
🗄️ RDS – Managed Databases
⚖️ Elastic Load Balancer – Traffic Distribution
🌍 Route 53 – DNS & Domain Management
📈 CloudWatch – Monitoring & Alerts
📧 SES – Email Service
⚡ Lambda – Serverless Computing
🌐 CloudFront – Content Delivery Network

🗺️ Recommended Learning Path

Regions & AZs → IAM → EC2 → S3 → VPC → RDS → ELB → Route 53 → CloudWatch → SES → Lambda → CloudFront

This order isn't arbitrary — it mirrors how a real application gets built: understand where things run, secure access, stand up compute, add storage, network it together, attach a database, load-balance and route traffic, monitor it, and finally add serverless + CDN for scale.

💡 Key Takeaway

Understanding Regions and Availability Zones first helps you design applications that are highly available, scalable, secure, and cost-effective on AWS.

Whether you're a System Administrator, DevOps Engineer, Cloud Engineer, or Solutions Architect, mastering these fundamentals will help you understand 80–90% of real-world AWS deployments.

⭐ Final Thought

Learn the foundation. Build with confidence. Scale without limits. That's the power of AWS!

Getting Started with Frappe Framework: From Basics to Architecture & Internals

Sai Praveen Sanapalli — Thu, 30 Jul 2026 15:39:30 +0000

If you've ever wondered how ERPNext, HRMS, Helpdesk, and dozens of other production-grade business apps got built so fast — the answer is Frappe. It's a metadata-driven, low-code and full-code Python framework that handles the boring-but-critical 80% (auth, permissions, forms, REST APIs, workflows, reports) so you can focus on actual business logic.

While learning Frappe, and turned them into this single guide. It's split into three parts:

Core Concepts — what Frappe is, how to set it up, and how apps/sites are structured
Development Essentials — the day-to-day toolkit: controllers, hooks, ORM, scripts, reports, APIs
Framework Internals — what actually happens under the hood, from request to response

Let's dive in.

Part 1: Core Concepts

What is Frappe?

Frappe is an open-source, metadata-driven, low-code/full-code Python framework for building modern business applications. It bundles database management, forms, auth, role-based permissions, workflows, automation, reports, and REST APIs out of the box — so you're not reinventing the wheel for every project.

It's the engine behind ERP, CRM, HRMS, Helpdesk, Manufacturing, Healthcare, Education, and many other custom business solutions.

Prerequisites

Before you install Bench (Frappe's CLI), make sure you have:

Requirement	Version
OS	Ubuntu 22.04 LTS+ / macOS / Linux
Python	3.11+
Node.js	20+
Yarn	1.22.x
Database	PostgreSQL 14+ / MariaDB 10.6+
Redis	6+
Git	latest
wkhtmltopdf	for PDF generation
Bench CLI	official CLI tool

Installing Bench

Bench is the official CLI tool used to set up and manage Frappe instances (technically called benches):

pip3 install frappe-bench
bench init my-bench
cd my-bench

The Bench Directory Structure

my-bench/
├── apps/            # Installed apps
├── sites/           # Sites (databases)
├── config/          # Config files
├── logs/            # Logs
├── sites/assets/     # Public assets
└── Procfile          # Process configuration

Creating an App

bench new-app my_app

This scaffolds a full app structure:

my_app/
├── my_app/
│   ├── doctype/      # Custom DocTypes
│   ├── report/       # Report scripts
│   ├── page/         # Custom pages
│   ├── api/          # API endpoints
│   ├── utils/        # Utility functions
│   ├── www/          # Public web assets (CSS, JS, images)
│   ├── hooks.py       # App hooks & overrides
│   ├── patches.txt    # Patches for migrations
│   └── modules.txt    # List of modules in the app
├── tests/             # Unit & integration tests
├── README.md
├── requirements.txt
└── setup.py

Creating a Site

bench new-site site.local

Every site gets its own isolated structure:

sites/site.local/
├── site_config.json   # DB, email, redis config
├── public/             # Public files (assets, uploads)
├── private/            # Private files (backups, keys)
└── logs/               # Site-specific logs

The key idea: each site has its own database, configuration, and files — this is what enables Frappe's multi-tenancy.

Installing an App into a Site

bench --site site.local install-app my_app
bench --site site.local migrate

This installs the app in the site and creates the necessary tables, assets, roles, and permissions.

Modules & DocTypes

A module groups related functionality within an app (e.g., Accounts, HR, Selling, Buying).

A DocType is the fundamental building block of Frappe — it defines the structure and behavior of data, and is rendered automatically into forms, lists, and reports.

Types of DocTypes:

Regular DocType — a standard doctype with its own database table
Single — a doctype with only one record (e.g., global settings)
Child Table — a table nested inside a parent DocType
Submittable DocType — supports workflow states (submit/cancel)
Virtual DocType — not stored in the DB; used for calculated/reporting data
Custom DocType — created by developers for custom requirements

Common Bench Commands

Command	Purpose
`bench start`	Start all services
`bench stop`	Stop all services
`bench restart`	Restart all services
`bench new-site <site>`	Create a new site
`bench get-app <app>`	Download an app
`bench install-app <app>`	Install app in a site
`bench migrate`	Run database migrations
`bench update`	Update apps
`bench --site <site> console`	Open the site console
`bench --site <site> backup`	Backup a site
`bench list-apps`	List installed apps
`bench list-sites`	List all sites

Notable Frappe Features

Authentication (Login, OAuth, LDAP, 2FA, Social Login), granular role-based permissions, dynamic form & list views, a REST API out of the box, workflow & automation engine, integrated Email/SMS/WhatsApp, background jobs & scheduler, built-in reports & dashboards, secure file management, multi-tenancy, and full extensibility — all under the MIT license.

Part 2: Development Essentials

Once your app and site are set up, here's the toolkit you'll actually use day-to-day.

1. Controllers & Methods

DocTypes ship with a Python controller class where you hook into the document lifecycle:

def before_insert(self): ...
def before_save(self): ...
def before_submit(self): ...
def on_update(self): ...
def on_submit(self): ...
def on_cancel(self): ...
def after_insert(self): ...
def on_trash(self): ...

These give you precise control over what happens at every stage of a document's life.

2. Users, Roles & Permissions

Frappe's permission system is deep:
Users & Roles,
Role Permission Manager,
Permission Levels (0–3),
User Permissions,
Document Permissions,
Permission Query Conditions,
Field-Level Permissions,
Share & Assign,
conditional (if-based) rules,
User/Role Profiles.

3. Hooks

hooks.py is where an app declares itself to the framework. Key hooks include:

doc_events → document event handlers
scheduler_events → background scheduled jobs
override_whitelisted_methods → override REST API methods
override_doctype_class → replace a DocType's controller
doctype_js → customize form behavior
app_include_js/css & web_include_js/css → load Desk/Website assets
jinja → custom template methods
fixtures → export app customizations
permission_query_conditions → custom list permissions
on_login / on_logout → authentication hooks

4. Database, ORM & Query

Frappe gives you multiple layers to work with data:

Frappe ORM (frappe.db, get_doc)
Query Builder (frappe.qb)
Raw SQL when you need it
Database transactions (commit/rollback)
Indexes & performance tuning
Full-text search
Support for both MariaDB and PostgreSQL

5. Scripts

Client Script (JS) — form events, field validation, UI customization, API calls
Server Script (Python) — business logic, scheduled tasks, event-based logic
System Console — execute Python/JS, debug & test, developer tools

6. Reports

Query Report — drag-and-drop fields, filters, groups, aggregations, charts & pivot
Script Report — custom Python logic with dynamic data
Reports support charts, pivots, indicators, export (Excel/CSV/PDF), scheduling & sharing

7. Print Formats

Build documents using Jinja templates — supports HTML/PDF output, dynamic data, company letterheads, custom styles, and watermarks/signatures.

8. Jinja Templates

Jinja is the templating engine at the heart of Frappe's UI — used in Print Formats, Email Templates, Web Pages, and List/Form Views. Supports variables, filters, control statements, inheritance, and macros/includes.

9. REST APIs & Webhooks

Every DocType gets REST endpoints automatically — list, get, create, update, delete, with filtering, pagination, and field selection:

GET /api/resource/Customer?fields=["name","email"]&filters=["disabled",0]

Webhooks let you fire real-time notifications on document events, triggered securely and reliably.

10. Document APIs & Methods

Common patterns you'll use constantly in server scripts:

frappe.new_doc(...)
frappe.get_doc(...)
frappe.get_list(...)
frappe.get_all(...)
frappe.get_cached_doc(...)
frappe.db.exists(...)
frappe.delete_doc(...)

doc.insert()
doc.save()
doc.submit()
doc.cancel()
doc.append(...)
doc.reload()
doc.db_set(...)

11. Desk

The modern workspace for your team: role-based desk, custom workspaces, modules, shortcuts, notifications, to-do/kanban/calendar views, real-time updates, search & filters, and custom fields/views.

12. Workflows

Automate business processes with workflow states, transitions, state-based permissions, transition conditions, approve/reject actions, email/notification triggers, multi-level approvals, and role-based access.

13. Profiling, Monitoring & Logging

Built-in profiler,
request profiling,
error logs,
background job logs,
scheduler logs,
slow query analysis,
performance monitoring,
site health monitoring — essential for debugging in production.

14. Social Logins & OAuth

Out of the box: Google Login, GitHub Login, LDAP Authentication, OAuth 2.0 Providers, SAML Authentication, OpenID Connect (OIDC), and custom OAuth providers.

15. Fixtures

Fixtures allow you to export customizations from one site and ship them with your application.
Custom Fields
Property Setters
Client Scripts
Server Scripts
Print Formats
Workspaces
Reports
Roles
Notification Templates

fixtures = [
    "Custom Field",
    "Property Setter",
    "Client Script"
]

Export fixtures:

bench export-fixtures

Why this matters:
these fourteen building blocks are what let teams ship scalable, secure business applications faster — with real-time integrations, automation, and enterprise-grade security baked in.

Part 3: Framework Internals — What Happens Under the Hood

This is the part that made Frappe click for me — understanding the actual architecture behind the abstractions.

Request Lifecycle

Every request flows through a clear, layered pipeline:

Browser
   ↓
Nginx
   ↓
Gunicorn
   ↓
Frappe Framework
   ↓
Authentication
   ↓
Permission Check
   ↓
Controller (Python)
   ↓
Business Logic
   ↓
ORM / Query Builder
   ↓
PostgreSQL / MariaDB
   ↓
Response (JSON / HTML)

Browser — user makes a request
Nginx — handles static files, SSL, and reverse proxying
Gunicorn — WSGI server that receives the request
Frappe Framework — routes the request to the application
Authentication — user is authenticated (session/token/OAuth)
Permission Check — permissions are validated
Controller (Python) — request is handled by the appropriate controller
Business Logic — application logic is executed
ORM / Query Builder — database operations (ORM or Query Builder)
PostgreSQL / MariaDB — data is read from or written to the database
Response (JSON / HTML) — response is sent back to the browser

Redis (In-Memory Store)

Redis is the central storage for queues, cache, sessions, locks, and realtime events. It handles: cache, session storage, the Redis Queue (RQ), pub/sub for realtime events, job metadata, distributed locks, rate limiting, and background job status.

Background Jobs (RQ)

RQ (Redis Queue) manages asynchronous tasks so users don't wait around for long-running operations:

frappe.enqueue(...)
   ↓
RQ Creates Job
   ↓
Redis Queue

Typical background jobs: email, SMS, WhatsApp, notifications, report generation, PDF generation, import/export, webhook calls, API sync, and scheduler jobs. Jobs are stored in Redis, and workers fetch and execute them.

Workers

Workers are long-running Python processes that monitor Redis queues, fetch jobs, and execute them asynchronously. There are three tiers:

Queue	Worker	Examples
Short Queue	Worker (Short)	Notifications, email, SMS, small updates
Default Queue	Worker (Default)	Business logic, API calls, data processing
Long Queue	Worker (Long)	Reports, imports, exports, PDF, AI jobs

Important: without running workers, queued jobs remain in Redis and are never executed.

Scheduler Events

The scheduler checks scheduled events defined in hooks.py, creates background jobs, and places them into Redis queues:

hooks.py (scheduler_events)
   ↓
Scheduler Process (bench schedule)
   ↓
Checks Schedule
   ↓
Calls frappe.enqueue()
   ↓
Redis Queue (RQ)
   ↓
Worker
   ↓
Execute Task

Schedule types supported: Hourly, Daily, Weekly, Monthly, and Cron (custom).

Crucially: the scheduler never executes jobs itself — it only enqueues them. Actual execution is always the worker's job.

Realtime (Socket.IO)

Realtime communication between server and clients — live notifications, progress bars, desk updates, and chat/collaboration — all powered by Socket.IO and Redis Pub/Sub.

Authentication & Session

Handles user authentication and session management: session management, API keys, token authentication (REST API), OAuth/social login, and role-based access — supporting multiple authentication methods.

Cache

Caching improves performance and reduces database load, via Redis cache, metadata cache, session cache, and document cache — for frequently accessed data.

Monitoring & Logging

Tools to monitor performance, errors, and system health: Error Log DocType, system logs (bench logs), slow query logs, background job logs, scheduler logs, bench doctor (health check), and the built-in profiler.

Database Layer

Handles all database operations and provides an abstraction over SQL: PostgreSQL/MariaDB support, Frappe ORM, Query Builder, transactions (commit/rollback), row-level locking, indexes & performance, and migrations (bench migrate).

Frappe Queue Management Architecture — Two Flows

A. User-Triggered Flow

User Click / Action (Generate Report, Send Email, etc.)
   ↓
frappe.enqueue() — Add job to queue
   ↓
Redis Queue (RQ) — Job stored in Redis
   ↓
Routed to Short / Default / Long Queue
   ↓
Worker executes the background job
   ↓
Database updated / Notification sent
   ↓
Job Completed (result stored or sent back)

B. Scheduled Layer

Time Reached (as per schedule)
   ↓
Scheduler Process (bench schedule) checks hooks.py Schedule Events
   ↓
Calls frappe.enqueue() — creates background job
   ↓
Redis Queue (RQ)
   ↓
Worker
   ↓
Execute Scheduled Task
   ↓
Job Completed

Example scheduled events: hourly tasks, daily reports, weekly cleanups, monthly jobs, custom cron jobs.

Common Bench Commands (Internals-Focused)

Command	Description
`bench start`	Start all services (web, worker, scheduler, etc.)
`bench stop`	Stop all services
`bench restart`	Restart all services
`bench status`	Check status of all services
`bench worker`	Start worker for default queue
`bench worker --queue short`	Start worker for short queue (fast tasks)
`bench worker --queue long`	Start worker for long queue (heavy tasks)
`bench schedule`	Start scheduler process
`bench migrate`	Run database migrations
`bench doctor`	Check bench health and system status
`bench show-pending-jobs`	Show pending jobs in all queues
`bench purge-jobs`	Purge completed/failed jobs from queues
`bench backup`	Create a backup of the site
`bench console`	Open Frappe console

Official Resources

Frappe Official Website: https://frappe.io/
Frappe Framework Documentation: https://docs.frappe.io/framework
ERPNext Documentation: https://docs.erpnext.com
Frappe GitHub Repository: https://github.com/frappe/frappe
ERPNext GitHub Repository: https://github.com/frappe/erpnext

Wrapping Up

Frappe's real power isn't any single feature — it's how metadata (DocTypes), events (hooks), and infrastructure (Redis, RQ, workers, scheduler) compose together into a cohesive system. Once you understand the request lifecycle and the queue architecture, the rest of the framework — controllers, permissions, workflows, reports — starts to feel like straightforward configuration on top of a solid foundation.

If you're building your first Frappe app, my suggestion:
start with bench new-app,
get a simple DocType working end-to-end (form → hook → API),
go read about workers and the scheduler.
The internals will make a lot more sense once you've felt the "front door" of the framework first.

Happy building! 🚀

If this was useful, drop a comment with what you're building on Frappe — always curious to see what people ship with it.

Complete WhatsApp Cloud API Setup Guide (2026) – From Facebook Account to Production Integration

Sai Praveen Sanapalli — Mon, 22 Jun 2026 20:08:44 +0000

WhatsApp has become one of the most important communication channels for businesses worldwide. With Meta's WhatsApp Cloud API, developers can integrate WhatsApp messaging directly into their applications without managing their own WhatsApp infrastructure.

However, many developers find the initial setup confusing because multiple Meta components are involved:

Facebook Account
Facebook Page
Meta Business Portfolio
Meta Developer Account
Meta App
WhatsApp Business Account (WABA)
System User
Access Tokens
Webhooks
Message Templates

This guide walks through the complete end-to-end setup process, from creating the required Meta assets to sending production WhatsApp messages through the Cloud API.

What You Will Build

By the end of this guide, you will have:

✅ Verified Meta Business Portfolio

✅ Meta Developer Account

✅ Meta App with WhatsApp Product

✅ WhatsApp Business Account (WABA)

✅ Verified Production Phone Number

✅ Permanent Access Token

✅ Webhook Configuration

✅ Approved Message Templates

✅ Production-Ready WhatsApp Cloud API Integration

WhatsApp Cloud API Architecture

Facebook Account
        │
        ▼
Facebook Page
        │
        ▼
Meta Business Portfolio
        │
        ▼
Meta App 
        │
        ▼
WhatsApp Business Account (WABA)
        │
        ▼
Phone Number
        │
        ▼
Cloud API
        │
        ▼
Your Application

1: Prerequisites

Before starting, ensure the following are available:

Required

Personal Facebook Account
Facebook Page
Business Name
Business Email Address
Business Website
Business Verification Documents (GST Certificate, Certificate of Incorporation, Udyam/MSME Certificate, Business PAN, or other valid business proof)
Mobile Number for WhatsApp (preferably a new number, should not be banned/restricted, and ideally not used with unofficial WhatsApp tools)
Debit/Credit Card (for billing setup)
Domain Name and HTTPS-enabled Public Server (for webhook configuration)

2. Facebook Account Creation and Facebook Page Linking

Before setting up a Meta Business Portfolio or WhatsApp Business Platform, you must have:

Facebook Personal Account

A Facebook Personal Account is the standard Facebook user account used to access:

Meta Business Portfolio (Business Manager)
Meta Business Suite
Meta Developer Portal
WhatsApp Business Platform

No special configuration is required. A normal Facebook account is sufficient.

Facebook Page

A Facebook Page represents your business or brand on Meta platforms.

A WhatsApp Business Account (WABA) is typically linked to a Facebook Page for business identity and management purposes.

Recommended Page Information

Configure the following details on the Facebook Page:

Page Name (Business/Brand Name)
Profile Picture (Company Logo)
Cover Photo
Business Description
Business Website
Business Email Address
Business Phone Number
Business Address (Optional)

These details help establish business identity and may assist during review and verification processes.

Scenario 1: No Facebook Account and No Facebook Page Exist

Step 1: Create a Facebook Personal Account

Go to Facebook.
Click Create New Account.
Enter your personal details.
Verify your email address and mobile number.
Complete your profile information.
Enable Two-Factor Authentication (2FA).

Step 2: Create a Facebook Page

Log in to your Facebook account.
Navigate to Pages.
Click Create New Page.
Enter:

Page Name
Category
Description
1. Add a profile picture and cover image.
2. Publish the page.
3. Facebook Personal Account created.
4. Facebook Page created.
5. The Facebook account automatically becomes the Page Admin.

Scenario 2: Facebook Account Exists, but No Facebook Page Exists

Step 1: Log in to Facebook

Use the existing Facebook account that will manage the business assets.

Step 2: Create a Facebook Page

Navigate to Pages.
Click Create New Page.
Enter:

Page Name
Category
Description
1. Add a profile picture and cover image.
2. Publish the page.
3. Existing Facebook Account is used.
4. New Facebook Page is created.
5. The Facebook account becomes the Page Admin.

Scenario 3: Facebook Account Exists and Facebook Page Already Exists

In this scenario, the Facebook Page is already owned or managed by another user or organization.

Step 1: Create or Use Your Facebook Account

Use the Facebook account that will be used for Meta Business Portfolio and WhatsApp Business Platform setup.

Step 2: Existing Page Admin Grants Access

The current Page Admin must:

Open the Facebook Page.
Navigate to:

Settings → Page Access

Click Add New under Facebook Access.
Search for the user's Facebook profile.
Send the invitation.

Step 3: Accept the Invitation

The invited user must:

Open Facebook notifications.
Review the Page access invitation.
Accept the invitation.

The user's Facebook account is linked to the existing Facebook Page.
The user can manage the Page according to the permissions granted by the Page Admin.

3. Create Meta Business Portfolio and Complete Business Verification

Create Business Portfolio

Go to:

https://business.facebook.com

Log in using your Facebook account.
Click Create Account.
Enter:

Business Name
Business Email
Your Name
1. Click Submit.

This creates your Meta Business Portfolio (formerly Business Manager).

Link Business Assets

Link Facebook Page

Navigate to:

Business Settings → Accounts → Pages

Add:

Existing Facebook Page

Create a New Facebook Page

Optional assets:

Instagram Account
Ad Account

Confirm Business Email

Meta sends a verification email to the business email address.

Open the email and confirm ownership.

Complete Business Verification

Navigate to:

Business Settings → Security Center

Click Start Verification.

Provide:

Legal Business Name
Business Address
Business Phone Number
Business Website (recommended)

Upload supporting documents such as:

Certificate of Incorporation
GST Registration Certificate
Udyam (MSME) Registration
Business License
Utility Bill or Bank Statement (if requested)

Verify Contact Information

Meta may ask to verify:

Business Email
Business Phone Number
Domain Ownership (if website is provided)

Verification Status

Track verification from:

Business Settings → Security Center

Business verification typically takes between 1 and 7 days.

4. Create Meta Developer Account and Meta App

Go to:

https://developers.facebook.com

Log in using your Facebook account.
Accept the Meta Developer Terms.
Complete email verification if prompted.
Navigate to:

My Apps → Create App

Select Business as the app type.
Enter:

App Name
Contact Email
Business Portfolio
1. Click Create App.

Add WhatsApp Product

Open the newly created app.
Click:

Add Product → WhatsApp → Set Up

Meta provides:

Test WhatsApp Business Account (WABA)
Test Phone Number
Temporary Access Token

These resources are intended for development and testing purposes. You can immediately test WhatsApp Cloud API requests before configuring production assets.

5. Add Production Phone Number

Navigate to:

https://developers.facebook.com
Developer Console → Select App → WhatsApp → API Setup

Click Add Phone Number.

Provide:

Business Name
Display Name
Business Category
Phone Number

Complete verification using:

SMS OTP
Voice Call OTP

Important Notes

The phone number:

Must not already be registered with a personal WhatsApp account
Must not already be registered with WhatsApp Business App

If the number is already registered with WhatsApp, it must be migrated before it can be used with WhatsApp Cloud API.

After successful verification:

Phone number is associated with the WABA
Meta reviews the display name
Application can use the number through Cloud API

6. Check Display Name Status

Navigate to:

Business Settings → Accounts → WhatsApp Accounts → Phone Numbers

WhatsApp Manager → Phone Numbers

Display Name Status:

Approved
Pending Review
Rejected

Only approved display names can be used for production messaging.

If rejected, update and resubmit the display name.

7. WhatsApp Business Account (WABA)

A WhatsApp Business Account (WABA) is the container that manages all WhatsApp Business Platform assets.

Meta typically creates or associates a WABA during the onboarding process when a production phone number is added.

Manage WABA from:

Business Settings → Accounts → WhatsApp Accounts
WhatsApp Manager

WABA Management Features

Business Information

WABA Name
Business Portfolio
Business Details

Phone Numbers

Add or Remove Phone Numbers
Display Name Status
Quality Rating

Message Templates

Create Templates
Submit Templates for Approval
View Template Status

Users & Permissions

Add Admins
Assign Access

Messaging Limits

View Messaging Limits
Monitor Quality Rating

Billing

Payment Method
Billing Information
Usage and Charges

8. Create a System User

Navigate to:

https://business.facebook.com
Business Settings → Users → System Users

Click Add
Enter a name
Select Admin System User
Click Create

System Users are used for server-to-server authentication and generating permanent access tokens for API Integratios.

9. Assign Assets to the System User

Select the System User.

Click:

Assign Assets

Assign:

WhatsApp Business Account (WABA)

Permissions:

whatsapp_business_management
whatsapp_business_messaging

Meta App

Permissions:

Full Control (Recommended)

Save changes.

10. Generate a Permanent Access Token

Open the System User.
Click Generate New Token.
Select the Meta App.
Select permissions:

whatsapp_business_management
whatsapp_business_messaging
1. Generate the token.
2. Securely store it.

This permanent access token is used by your application to access the WhatsApp Cloud API in production.

11. Configure Billing

Navigate to:

WhatsApp Manager → Billing

Configure:

Payment Method
Billing Information

Billing allows you to:

Add payment methods
View conversation charges
Monitor usage and costs
Manage billing information

12. Configure Webhooks

Navigate to:

https://developers.facebook.com
Developer Console → Your App → WhatsApp → Configuration

Configure:

Callback URL

The endpoint that receives webhook events from Meta.

Example:

https://yourdomain.com/api/method/whatsapp.webhook

Verify Token

Custom secret token used during webhook verification.

Subscribe to Webhook Fields

Recommended:

messages
message_status
message_template_status_update

Webhook Use Cases

Receive:

Incoming Messages
Delivery Reports
Read Receipts
Message Status Updates
Template Status Updates

Webhook configuration is required for two-way messaging and real-time event processing.

13. Create Message Templates

Navigate to:

WhatsApp Manager → Message Templates

Create templates for:

OTP Messages
Welcome Messages
Notifications
Payment Reminders
Appointment Reminders
Marketing Campaigns

After creating a template:

Select the template category (Marketing, Utility, Authentication).
Configure the message content and variables.
Submit the template for Meta review.

Template Status

Pending
Approved
Rejected

Template approval typically takes from a few minutes to several hours, although it may take longer in some cases.

Only approved templates can be used to initiate conversations.

14. Test WhatsApp API Integration

Use:

Phone Number ID
Permanent Access Token

Testing Methods

Postman Testing

Postman Collection:

https://www.postman.com/meta/whatsapp-business-platform/collection

Provide:

Phone Number ID
Permanent Access Token

This is the most common method used for API testing and troubleshooting.

Application/API Integration Testing

Integrate the WhatsApp Cloud API into your application and test using your application code.

Examples: Python, Node.js,Java

Validate complete end-to-end integration.

Test the Following APIs

Send Message API

Send a basic text message.

Template Message API

Send an approved template.

Media Message API

Send:

Images
Documents
Audio
Video

Verify Integration

Confirm:

Messages are delivered successfully.
Incoming messages are received.
Webhooks are triggered correctly.
Delivery status updates are received.
Read receipts are received.
Template messages are delivered successfully.
Media messages are delivered successfully.

Resolve any API, webhook, permission, or configuration issues before moving to production.

15. Go Live

After all configurations are complete and verified, your WhatsApp Cloud API integration is ready for production use.

Go-Live Checklist

✓ Business Verification Completed
✓ Approved Display Name
✓ Verified Production Phone Number
✓ Approved Message Templates
✓ Permanent Access Token Generated
✓ Webhooks Configured and Working
✓ Billing Configured
✓ API Integration Tested Successfully
✓ Required Users and Permissions Configured

Once the checklist is complete, the WhatsApp Business Platform can be used for production messaging.

16. Production Integration Credentials Reference

After completing the WhatsApp Cloud API setup, collect and securely store the following credentials.

Credential	Purpose	Required For
App ID	Unique identifier of the Meta App	API management and token generation
App Secret	Secret key associated with the Meta App	Server-to-server authentication and security operations
Business Portfolio ID (Business Manager ID)	Identifier of the Meta Business Portfolio	Business asset management
WhatsApp Business Account ID (WABA ID)	Identifier of the WhatsApp Business Account	Template management and account management APIs
Phone Number ID	Identifier of the WhatsApp-enabled phone number	Sending messages through Cloud API
Permanent Access Token	Authentication token generated for the System User	All production API requests
Verify Token	Custom token configured during webhook setup	Webhook verification
Webhook Callback URL	Public HTTPS endpoint that receives Meta events	Incoming messages and status updates

Resources 👍

Meta WhatsApp Business Platform Documentation

https://developers.facebook.com/documentation/business-messaging/whatsapp/overview

Postman Collection

https://www.postman.com/meta/whatsapp-business-platform/collection

Conclusion

Setting up WhatsApp Cloud API involves several Meta services, including Business Portfolio, WABA, Developer Apps, System Users, Access Tokens, and Webhooks. While the onboarding process may initially seem complex, once configured correctly, it provides a scalable and reliable platform for integrating WhatsApp messaging into business applications.

Following this guide will help you move from a simple Facebook account to a fully production-ready WhatsApp Cloud API integration.

# 🚀 70+ VS Code Extensions Every Developer Should Know

Sai Praveen Sanapalli — Fri, 05 Jun 2026 19:02:20 +0000

Visual Studio Code is one of the most popular code editors among developers. While VS Code is powerful out of the box, the right extensions can significantly improve productivity, code quality, debugging, collaboration, and workflow management.

Here are 70+ useful VS Code extensions categorized by use case.

🐍 Python & Data Science

Python – Official Python support with debugging, IntelliSense, linting, and environment management.
Pylance – Fast IntelliSense, type checking, and auto-import suggestions.
Ruff – Extremely fast Python linter and formatter.
Black Formatter – Automatically formats Python code consistently.
Flake8 – Enforces coding standards and detects issues.
isort – Organizes and sorts imports automatically.
Python Test Explorer – Run and manage tests directly in VS Code.
Jupyter – Create and run notebooks inside VS Code.
Indent Rainbow – Makes indentation levels easier to read.

🌐 Web & Frontend Development

ES7+ React/Redux Snippets – Speed up React development with ready-made snippets.
Tailwind CSS IntelliSense – Autocomplete and validation for Tailwind CSS.
Prettier – Automatically formats code on save.
HTML CSS Support – Improves HTML and CSS IntelliSense.
CSS Peek – Jump directly to CSS definitions.
Auto Rename Tag – Renames paired HTML tags automatically.
Auto Close Tag – Inserts closing tags automatically.
Live Server – Launch local projects with live reload.
Live Share – Collaborate with teammates in real time.
Jest – Run and debug Jest tests directly.

🗄️ Databases

SQLTools – Connect to and query multiple databases.
PostgreSQL – Browse and run PostgreSQL queries.
MongoDB for VS Code – Explore collections and execute queries.
SQLite Viewer – Open SQLite databases directly.
Prisma – IntelliSense and formatting for Prisma schemas.
Rainbow CSV – Makes CSV files easier to read and analyze.

🔀 Git & GitHub

GitLens – Advanced Git insights and history tracking.
Git Graph – Visualize branches and commit history.
GitHub Pull Requests – Review and manage pull requests.
GitHub Actions – View workflow runs and statuses.
GitHub Codespaces – Launch cloud development environments.
GitHub Repositories – Browse repositories without cloning.
Settings Sync – Synchronize settings and extensions across devices.

✅ Code Quality & Formatting

ESLint – JavaScript and TypeScript linting.
Error Lens – Displays errors directly inline.
SonarQube for IDE – Detects bugs, vulnerabilities, and code smells.
Better Comments – Organize comments using visual highlights.
Code Spell Checker – Finds spelling mistakes in code and documentation.
DotENV – Syntax highlighting for environment files.

🔌 API Testing & Debugging

Thunder Client – Lightweight API testing inside VS Code.
REST Client – Execute HTTP requests from text files.
Turbo Console Log – Generate console logs instantly.

☁️ DevOps & Cloud

Docker – Manage containers and images.
Remote SSH – Develop directly on remote servers.
Dev Containers – Open projects inside containers.
Kubernetes – Manage clusters and workloads.
Terraform – Infrastructure as Code support.
YAML – Validation and IntelliSense for YAML files.
AWS Toolkit – Access AWS services directly from VS Code.
Makefile Tools – Work efficiently with Makefiles.

📝 Documentation & Diagrams

Markdown All in One – Productivity tools for Markdown editing.
Markdown Preview Enhanced – Rich Markdown preview and exports.
Mermaid Charts – Create flowcharts and diagrams with Mermaid.
Draw.io Integration – Build architecture and workflow diagrams.
CodeSnap – Create beautiful code screenshots.
vscode-pdf – View PDFs without leaving VS Code.

⚡ Productivity & Workflow

Path IntelliSense – Auto-complete file paths.
Project Manager – Quickly switch between projects.
Bookmarks – Save important code locations.
Todo Tree – Organize TODO and FIXME comments.
JSON Crack – Visualize JSON structures.
Peacock – Color-code workspaces.
Pomodoro Timer – Stay focused with timed work sessions.
WakaTime – Track coding activity automatically.
VSCodeVim – Vim keybindings for VS Code users.
One Dark Pro – Popular developer-friendly theme.
Material Icon Theme – Beautiful file and folder icons.
Color Highlight – Preview colors directly in code.
Paste JSON as Code – Generate typed models from JSON instantly.

💡 Pro Tip

Choose extensions based on your workflow, not popularity.
Too many extensions can impact performance and increase resource usage.
Keep your setup lean, fast, and productive. 🚀

What are your favorite VS Code extensions?

Drop your recommendations in the comments and help other developers discover useful tools.

Happy Coding! 💻

# AWS SES Setup Guide: Domain Verification, SMTP Configuration, DKIM, SPF & DMARC

Sai Praveen Sanapalli — Wed, 03 Jun 2026 18:55:53 +0000

Email delivery is a critical component of modern applications. Whether you're sending OTPs, transactional notifications, account alerts, invoices, or marketing campaigns, reliable email delivery is essential.

In this guide, we'll walk through the complete setup of Amazon Simple Email Service (AWS SES), including domain verification, DKIM, SPF, DMARC, SMTP credentials, and production access.

What is AWS SES?

Amazon Simple Email Service (AWS SES) is a cloud-based email service that enables businesses and developers to send and receive emails securely and at scale.

Key Benefits

Cost-effective email delivery
High deliverability
SMTP and API support
Easy integration with applications
Reputation monitoring
Scalable infrastructure
Security through SPF, DKIM, and DMARC

Step 1: Before You Start

Before configuring AWS SES, complete the following prerequisites.

Login to AWS Console

Select AWS Region

For users in India, use:

Asia Pacific (Mumbai) – ap-south-1

Important:
SMTP credentials are region-specific.
For SMTP and SMS credential generation, it is recommended to use the Mumbai (ap-south-1) region.

Create Identity Using Your Domain

Example:

alerts.yourcompany.com

AWS SES uses this domain identity for email authentication and reputation management.

Step 2: Create Domain Identity

Open AWS Console
Search for SES
Open Amazon Simple Email Service
Navigate to Verified Identities
Click Create Identity
Select Identity Type → Domain
Enter your domain

Example:

alerts.yourcompany.com

Enable Easy DKIM
Click Create Identity

AWS SES will generate:

TXT record for domain verification
Three DKIM CNAME records

Step 3: Configure DNS Records

Add the records generated by SES to your DNS provider.

TXT Record (Domain Verification)

Type: TXT
Value: amazonses-verification-token

DKIM Records

Type: CNAME
Count: 3

AWS provides these automatically.

SPF Record

Type: TXT

Value:
v=spf1 include:amazonses.com -all

SPF authorizes Amazon SES to send emails on behalf of your domain.

Step 4: Route 53 Configuration (Optional)

If your domain is hosted in Route 53:

Open Route 53
Select Hosted Zone
Add TXT verification record
Add DKIM CNAME records
Save changes

DNS propagation generally completes within:

5–15 minutes

Step 5: Configure Custom MAIL FROM Domain

Using a custom MAIL FROM domain improves deliverability and branding.

Example:

mail.alerts.yourcompany.com

Navigate to:

SES → Verified Identities → Domain → MAIL FROM Domain

Select:

Use Custom MAIL FROM Domain

Add MX Record

Type: MX

Value:
10 feedback-smtp.ap-south-1.amazonses.com

Add SPF Record

Type: TXT

Value:
v=spf1 include:amazonses.com -all

Step 6: Create Configuration Set (Optional but Recommended for monitoring)

Configuration Sets help monitor:

Deliverability
Bounce rates
Complaint rates
Reputation metrics

Steps:

Open SES
Navigate to Configuration Sets
Click Create Configuration Set
Enter a name

Example:

alerts-config

Enable Reputation Metrics
Attach SNS or CloudWatch event destinations

Step 7: Request Production Access

New AWS SES accounts start in Sandbox Mode.

Sandbox restrictions:

Can only send to verified email addresses
Limited sending quotas

To move to production:

Open SES Dashboard
Select Request Production Access
Fill in:

Use Case: Transactional Emails
Email Type: Transactional
Website: https://yourcompany.com

Approval typically takes:

2–24 hours

Step 8: Create SMTP Credentials

Navigate to:

SES → SMTP Settings

Click:

Create SMTP Credentials

AWS creates an IAM user and generates:

SMTP Username
SMTP Password

SMTP Endpoint (Mumbai Region)

Host:
email-smtp.ap-south-1.amazonaws.com

Port:
587

Encryption:
TLS

Important

Always use the SMTP endpoint that matches the region where credentials were generated.

Step 9: Test Email Delivery

You can test email delivery using:

Option 1

SMTP integration from your application.

Option 2

AWS SES test email functionality.

Option 3

Python Boto3 SDK.

After receiving the email:

Open Gmail → Show Original

Verify:

SPF: PASS
DKIM: PASS
DMARC: PASS

Step 10: Configure DMARC

DMARC adds an additional layer of protection against email spoofing.

Create:

Type: TXT

Host:
_dmarc.alerts.yourcompany.com

Value:
v=DMARC1; p=none; rua=mailto:admin@yourcompany.com;

After monitoring reports, you can move from:

p=none

p=quarantine

and eventually

p=reject

for stronger protection.

Email Deliverability Best Practices

Warm Up New Domains

Start with:

10–20 emails per day

and gradually increase volume.

Maintain Low Bounce Rates

Recommended:

Bounce Rate < 5%

Maintain Low Complaint Rates

Recommended:

Complaint Rate < 0.1%

Send Multipart Emails

Always send:

HTML version
Plain text version

Monitor Reputation Dashboard

Review:

Delivery rates
Bounce rates
Complaint rates
Reputation status

regularly.

High-Level Email Flow

Application
      ↓
AWS SES
      ↓
Domain Verification
      ↓
SPF + DKIM + DMARC
      ↓
Recipient Inbox
      ↓
High Deliverability

Conclusion

AWS SES provides a reliable, scalable, and cost-effective solution for sending transactional and notification emails. By properly configuring Domain Verification, DKIM, SPF, DMARC, Custom MAIL FROM, and SMTP credentials, you can significantly improve email deliverability and protect your domain reputation.

If you're building SaaS platforms, ERP systems, notification services, fintech applications, or customer communication platforms, AWS SES is one of the most efficient email delivery services available today.

DEV Community: Sai Praveen Sanapalli

CDN Explained: How Content Delivery Networks Work — A Complete Beginner's Guide

Table of Contents

What is a CDN?

Why CDN is Needed

How a CDN Works (Step by Step)

1. DNS Resolution

2. User Request Reaches the CDN

3. Edge Server Checks the Cache

4. CDN Fetches Content from the Origin

5. CDN Caches the Content

6. Subsequent Requests

7. Cache Expiration

CDN Architecture

Key Components of a CDN

a. Origin Server

b. Edge Servers (PoPs — Points of Presence)

c. DNS Routing / Anycast

d. Cache Layer

e. Load Balancer

f. Origin Shield

What Content a CDN Delivers

CDN for JavaScript, APIs, and Dynamic Websites

CDN for JavaScript

CDN for APIs

Caching Strategies

Cache Hit vs Cache Miss

TTL, Cache Invalidation, and Cache Busting

Browser Cache vs CDN Cache

DNS Alone Is Not a CDN

Real-World Examples

Popular CDN Providers

Benefits of Using a CDN

Challenges and Limitations

When Should You Use a CDN?

How to Check Which CDN a Site Uses

Summary

PostgreSQL Replication: The Complete Guide to Read Replicas, Architecture, and Setup

Table of Contents

What Is a Read Replica?

Why Read Replicas Are Needed

Primary vs Replica: Key Differences

How Replication Works

Replication Flow

Synchronous, Asynchronous & Semi-Synchronous Replication

Asynchronous Replication (default)

Synchronous Replication

Semi-Synchronous Replication

Replication Lag & Monitoring

Check connected replicas (run on primary)

Count active replicas

Check replication lag in time (run on replica)

Check replication slots

Check WAL retained per slot

Check WAL directory size

Check WAL receiver status (run on replica)

Types of Replication in PostgreSQL

PostgreSQL Replication Architecture

Replication Components — Detailed Description

Checking PostgreSQL Activity and Storage

Connections and active queries

Database size

Top 20 largest tables

Primary Server Configuration

1. Locate the configuration file

2. Check current replication-related settings

3. Update postgresql.conf

4. Configure pg_hba.conf to allow replica connections

5. Reload / restart PostgreSQL

6. Create the replication user

Replica Server Configuration

Setting Up a Replica (Local & Remote)

Local Replica (Same Server)

Remote Replica (Different Server)

Verifying and Testing Replication

On the primary — confirm the replica is connected

On the replica — confirm it's in recovery (standby) mode

Test that writes are blocked on the replica

Test that data actually replicates

Summary

3. Update `postgresql.conf`

4. Configure `pg_hba.conf` to allow replica connections