DEV Community: Kfir

From Passive FastAPI Developer to Real FastAPI Engineer- Part 2

Kfir — Mon, 08 Dec 2025 03:28:33 +0000

Photo by Kaue Barbier: https://www.pexels.com/photo/28182837/

Your First Raw ASGI App (No Frameworks Allowed).

Before FastAPI.

Before Starlette.

Before Uvicorn.

There is ASGI- the low-level async contract that makes modern Python web apps possible.

In Part 1, we learned how HTTP works at the byte level. Now in Part 2, you’re going to build an ASGI app from scratch.

No router.

No response class.

No request.query_params.

Just you and the ASGI spec.

Let’s turn the black box into a glass box.

1. Why Build a Raw ASGI App?

Most FastAPI developers never touch ASGI.

Most don’t know what’s inside a request.

Most don’t know what Uvicorn gives them.

Most don’t know what Starlette abstracts.

This chapter fixes that.

By the end, you will understand:

How a web server calls your ASGI application
What a scope is.
How receive() and send() work.
How a single HTTP request becomes events.
The difference between WSGI (sync) and ASGI (async).
What FastAPI really sits on top of.

Once you know this layer, FastAPI becomes predictable, not magical.

2. ASGI in 60 Seconds

ASGI = Asynchronous Server Gateway Interface The modern replacement for WSGI.

WSGI ASGI Sync Async One call, one response Event-driven HTTP only HTTP + WebSocket + lifespan Blocking Non-blocking.

The ASGI callable signature

async def app(scope, receive, send):
    ...

Where:

Parameter Meaning scope Immutable connection info (method, headers, path, etc.) receive() Async function: read events from server (request body, disconnect) send() Async function: send events to server (response start/body)

3. Step-by-Step: Build a Raw ASGI App

Create a file:

raw_asgi_app.py

Paste this:

# raw_asgi_app.py

async def app(scope, receive, send):
    print("=== SCOPE RECEIVED ===")
    print(scope)
    # Only handle HTTP requests
    if scope["type"] != "http":
        return
    # Wait for request event (headers/body)
    event = await receive()
    print("=== REQUEST EVENT ===")
    print(event)
    body = b"Hello from raw ASGI!"
    # Send HTTP start
    await send({
        "type": "http.response.start",
        "status": 200,
        "headers": [(b"content-type", b"text/plain")]
    })
    # Send response body
    await send({
        "type": "http.response.body",
        "body": body,
    })

4. Run the App With Uvicorn

Even though we didn’t build routing or server logic, Uvicorn can execute any ASGI app :

uvicorn raw_asgi_app:app --host 127.0.0.1 --port 8000

Test it:

curl "http://127.0.0.1:8000/hello?name=kfir"

Watch your terminal print:

The scope
The request event
The ASGI lifecycle

This is the moment where ASGI becomes real.

5. Understanding the ASGI Scope

Example (shortened):

{
    "type": "http",
    "method": "GET",
    "path": "/hello",
    "query_string": b"name=kfir",
    "headers": [
        (b"host", b"127.0.0.1:8000"),
        (b"user-agent", b"curl/8.0"),
        (b"accept", b"*/*")
    ],
    "client": ("127.0.0.1", 53921),
    "server": ("127.0.0.1", 8000)
}

This is exactly the same information Starlette uses to build a Request object.

6. Understanding receive() Events

For HTTP requests:

{
    "type": "http.request",
    "body": b"",
    "more_body": False
}

For clients disconnecting:

{"type": "http.disconnect"}

7. Understanding send() Events

Start the HTTP response:

{
    "type": "http.response.start",
    "status": 200,
    "headers": [...],
}

Send body:

{
    "type": "http.response.body",
    "body": b"...",
}

If streaming:

{"body": chunk, "more_body": True}

8. Diagram — The ASGI Lifecycle

Client (curl)
   │
   ▼
Raw HTTP bytes
   │
   ▼
Uvicorn (parsing, connection, events)
   │
   ▼
ASGI App (your app)
   │ ▲
 send() │ receive()
   ▼ │
Response events
   │
   ▼
Uvicorn → TCP → Client

9. Compare This With WSGI

WSGI:

def app(environ, start_response):
    ...

ASGI:

async def app(scope, receive, send):
    ...

WSGI gives you:

sync
blocking
no streaming
no WebSockets

ASGI gives you:

async
streaming
background tasks
WebSockets
HTTP/2 support

10. Quick Exercises

1. Return JSON manually

body = b'{"msg":"hello"}'
headers = [(b"content-type", b"application/json")]

2. Parse query params manually

qs = scope["query_string"].decode()

3. Print content length

for name, value in scope["headers"]:
    if name == b"content-length":
        print("Content-Length:", value.decode())

4. Respond in two chunks (streaming)

await send({"type": "http.response.body", "body": b"Hello ", "more_body": True})
await send({"type": "http.response.body", "body": b"Kfir!"})

Wrapping Up: Why You Just Built ASGI by Hand

By writing an ASGI app without FastAPI, Starlette, or any framework, you’ve crossed an important threshold: you now understand what actually happens before any modern Python web framework can do its job.

You saw how:

A TCP connection becomes raw HTTP bytes.
Those bytes become an ASGI scope + events.
Your Python code responds using send()/receive() .
The entire request/response lifecycle is just structured events , not magic.

This understanding is what separates a FastAPI user from a FastAPI engineer.

Every routing decision, middleware execution, background task, and WebSocket message ultimately reduces to the exact pattern you implemented manually.

If you can build this tiny ASGI app from scratch, you can understand, debug, and optimize any modern Python web stack- from Uvicorn workers to Starlette internals all the way up to FastAPI dependencies.

Congratulations. You’re officially “under the hood.”

Official References (Highly Recommended)

These are the authoritative sources behind everything in this blog:

From Passive FastAPI Developer to Real FastAPI Engineer- Part 1: ASGI

Kfir — Fri, 21 Nov 2025 15:42:25 +0000

Photo by Kaue Barbier: https://www.pexels.com/photo/28182842/

Understanding ASGI by Breaking Down an HTTP Request

Modern Python web frameworks feel effortless- you write a function, return some JSON, and boom: a web app. But underneath that smooth layer lies a ton of complexity: raw bytes over TCP, state machines, protocols, concurrency, and error-prone details you never want to touch.

ASGI exists to shield you from that pain. Let’s break an HTTP request down and see how ASGI fits into the picture.

What is ASGI?

ASGI (Asynchronous Server Gateway Interface) is a Python specification that defines how web servers communicate with asynchronous Python applications.

Official spec: https://asgi.readthedocs.io/en/latest/

You can think of it as the evolution of WSGI, designed for modern async apps, HTTP/2, and WebSockets.

Why Do We Need ASGI?

Inside every web server, there are three conceptual layers:

Transport -> Protocol -> Application Logic
TCP/SSL HTTP/WS Your FastAPI code

The problem:

If every framework had to re-implement TCP handling, HTTP parsing, connection lifecycle, etc., we’d live in a world of endless duplicated code and subtle bugs.

ASGI proposes a clean split into two Python components:

Protocol Server (e.g., Uvicorn, Hypercorn)

Handles raw network I/O
Transforms bytes into structured ASGI events

2. Application (e.g., Starlette, FastAPI, custom ASGI apps)

Receives events like http.request
Returns events like http.response.start and http.response.body

This “bridge” is ASGI:

Protocol Server <---- ASGI ----> Application

A Quick Timeline of Request Interfaces

Year Spec Notes:

1993 CGI Process-per-request. Ancient, slow.

2003 WSGI (PEP 333) Standardized sync Python apps.

2010 WSGI 1.0.1 (PEP 3333) Updated for Python 3.

2016 ASGI Async, event-based design.

2019 ASGI 3.0 Modern form used today.

Why WSGI Wasn’t Enough

WSGI apps are synchronous and take exactly two parameters:

def app(environ, start_response):
    start_response("200 OK", [("Content-Type", "text/plain")])
    return [b"hello"]

This works for HTTP/1.1 but fails for:

concurrency
streaming
long-lived connections
WebSockets

WSGI can’t represent async behavior or event-driven protocols.

ASGI’s Core Idea

An ASGI application is an async callable :

async def app(scope, receive, send):
    ...

scope → Metadata about the connection (type, path, headers, etc.)
receive() → Wait for events from server (e.g., request body chunks)
send() → Emit events back (response start, response body, WebSocket messages)

This event system is the real power. It makes communication flexible and supports full-duplex protocols.

A Minimal ASGI App (Raw)

async def app(scope, receive, send):
    assert scope["type"] == "http"

await send({
        "type": "http.response.start",
        "status": 200,
        "headers": [(b"content-type", b"text/plain")],
    })
    await send({
        "type": "http.response.body",
        "body": b"Hello from raw ASGI!",
    })

Run it with Uvicorn:

uvicorn example:app

HTTP Request Flow in WSGI vs ASGI

WSGI Flow (Sync)

Client
  |
HTTP Request
  |
WSGI Server parses bytes
  |
(environ, start_response)
  |
WSGI App
  |
Iterables of bytes
  |
WSGI Server → HTTP Response

No events. No async. No real-time messaging.

ASGI Flow (Event-Based, Async)

Client
  |
Raw Bytes
  |
Protocol Server (Uvicorn / Daphne)
  |
ASGI Event: "http.request", "http.disconnect"
  |
async app(scope, receive, send)
  |
Your app emits events:
  - "http.response.start"
  - "http.response.body"
  - "websocket.accept"
  - "websocket.send"

This model is more general, flexible, and future-proof.

Why ASGI Matters

1. Concurrency

Async I/O = thousands of simultaneous connections.

2. WebSockets Support

WSGI can’t do WebSockets.

ASGI makes WebSockets just another protocol supported by events.

3. Full-Duplex Communication

Send and receive independently- essential for:

WebSockets
HTTP streaming
Server-Sent Events
Background events

4. Protocol Independence

ASGI officially supports:

http
websocket
lifespan (startup/shutdown events)

More protocols can be added without rewriting frameworks.

A Tiny Diagram: ASGI in FastAPI

      ┌──────────────────┐
      │ Your FastAPI │
      │ App │
      └────────┬─────────┘
               │ ASGI callable
               ▼
        ASGI Interface
               ▲
               │ events
      ┌────────┴─────────┐
      │ Uvicorn Server │
      │ (Protocol Layer) │
      └──────────────────┘

You “inject” your application into the protocol server.

The server handles all low-level details- your app just reacts to events.

Final Summary

ASGI gives us:

async concurrency
flexible event-driven communication
WebSocket support
protocol independence
clean separation of logic vs transport
a standard interface for modern Python web servers

It’s the foundation that makes Starlette and FastAPI so fast and the reason you never have to manipulate raw HTTP bytes yourself.

References:

The ASGI official specification at https://asgi.readthedocs.io/en/latest/
The WSGI standard via PEP 333 at https://peps.python.org/pep-0333/ and PEP 3333 at https://peps.python.org/pep-3333/, the historical CGI/1.1 RFC at https://www.rfc-editor.org/rfc/rfc3875
The Uvicorn ASGI server documentation at https://www.uvicorn.org/
The Starlette framework documentation at https://www.starlette.io/
Tmhe HTTP/1.1 protocol definition at https://www.rfc-editor.org/rfc/rfc7230, and the WebSocket protocol spec at https://www.rfc-editor.org/rfc/rfc6455

Why I Use curl Instead of Postman: Learning HTTP by Feel

Kfir — Mon, 10 Nov 2025 03:01:51 +0000

Photo by Kelly : https://www.pexels.com/photo/motor-bike-running-close-up-photography-2519374/

Sometimes you don’t need another GUI. You need to touch the protocol. While everyone opens Postman tabs, I open my terminal and type:

curl -X POST http://127.0.0.1:8000/api/shorten \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com"}'

That’s it- raw, direct, and honest. No buttons, no noise. Just HTTP, right under your fingertips.

Learning Through the Fingertips

Typing the request yourself makes every part of HTTP visible.

-X POST chooses the verb with intent
-H sets the headers precisely
-d sends the data explicitly

And when you hit enter, you see exactly what the server gives back:

{"short_url": "http://localhost:8000/000001"}

Every curl command teaches you the rhythm of request and response- the web’s real heartbeat.

Seeing the Protocol, Not the UI

When you use curl -v, the terminal becomes your microscope:

curl -v http://127.0.0.1:8000/api/000001

You see every move:

> GET /api/000001 HTTP/1.1
> Host: 127.0.0.1:8000
> User-Agent: curl/8.7.1
> Accept: */*
< HTTP/1.1 307 Temporary Redirect
< location: https://example.com/

The protocol becomes transparent. You understand what’s happening, not just that something happened.

Discovering More

The beauty of curl is in its depth.

You don’t have to memorize- you explore.

curl --help
curl --help all | less

Each flag opens a new door like:

-I fetch headers only
-L follow redirects automatically
-o save output to a file
-w "%{http_code}" show only the response code
-s silent mode (no progress bar)
-S show errors even when silent
-k ignore SSL certificate checks
-x http://proxy:8080 use a proxy

The official docs are an endless rabbit hole of discovery: https://curl.se/docs/manpage.html

If you don’t want to leave the terminal, you can explore everything from the CLI itself. Here are a few ways to learn curl directly through your shell:

# See all common options with short descriptions
curl --help

# See every possible flag and advanced usage
curl --help all | less

# Get a manual-style explanation (same as the website docs)
man curl

# Search inside the manual for a specific flag
man curl | grep timeout

# Quick reminder for a specific option
curl --help | grep -i header

This is the beauty of curl: the docs live right where you work. You don’t have to Google anything- the knowledge is built into the tool.

How curl Fits in Everyday Dev Life

curl is not just for testing APIs. It’s a daily development companion.

1. Health checks

curl -fsSL http://localhost:8000/health || echo "Service down"

2. Quick response code check

curl -s -o /dev/null -w "%{http_code}\n" http://localhost:8000

3. Debugging with headers

curl -v -X GET http://localhost:8000/api/items
curl -i http://localhost:8000/api/status

4. Testing authentication

curl -u admin:password http://localhost:8000/api/users

5. Sending JSON data

curl -X POST http://localhost:8000/api/shorten \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com"}'

6. Simulating different HTTP verbs

curl -X PUT http://localhost:8000/api/items/1 -d '{"name": "updated"}'
curl -X DELETE http://localhost:8000/api/items/1

7. Working inside Docker containers

docker exec -it tinyurl-app-fastapi-1 curl http://redis:6379

8. Testing redirects and caching

curl -L http://localhost:8000/short/123
curl -I http://localhost:8000/static/style.css

9. Monitoring endpoints continuously

watch -n 2 'curl -s -o /dev/null -w "%{http_code}" http://localhost:8000/health'

10. Downloading and uploading files

curl -O https://example.com/file.zip
curl -T myfile.txt ftp://ftp.example.com/ --user user:password

The Terminal Teaches Clarity

When you write requests in curl, you’re not hiding behind tools. You’re speaking to your server directly.

Each request is a sentence. Each flag is a verb. Each header is a whisper between client and server.

curl slows you down just enough to see what’s really happening. And once you see it, you never unsee it.

Feel the Protocol

curl is how you think in HTTP. It’s how you debug, learn, and build with precision. It’s that small command you reach for when nothing else feels right.

So the next time you open your terminal, type curl and listen. The protocol has been trying to talk to you all along.

Shipping FastAPI Like a Pro: My CI/CD Pipeline for TinyURL

Kfir — Sun, 02 Nov 2025 05:06:03 +0000

Photo by Jan Zakelj: https://www.pexels.com/photo/a-person-holding-yellow-pipes-9389356/

When I first deployed TinyURL- my FastAPI + Postgres + Nginx URL shortener-I wanted a workflow that felt real, not just docker compose up on my laptop. So I built a simple but solid CI/CD pipeline using GitHub Actions that runs tests, builds containers, and deploys automatically.

Here’s what I learned and how it all fits together.

1. CI/CD isn’t about tools- it’s about trust

The main goal wasn’t automation for its own sake. It was to reach a point where every push to main could safely go live- no surprises, no “works on my machine.”

That mindset helped me design a pipeline that checks, builds, and ships with zero manual steps.

2. The build pipeline: test early, build once

Here’s a simplified view of my GitHub Actions workflow (.github/workflows/deploy.yml):

name: Deploy TinyURL

on:
  push:
    branches:
      - main
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repo
        uses: actions/checkout@v4
      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: 3.11
      - name: Install dependencies
        run: pip install -r requirements.txt
      - name: Run tests
        run: pytest -q
      - name: Build Docker images
        run: docker compose -f docker-compose.prod.yml build
      - name: Deploy via SSH
        env:
          HOST: ${{ secrets.EC2_HOST }}
          KEY: ${{ secrets.EC2_SSH_KEY }}
        run: |
          echo "$KEY" > key.pem
          chmod 600 key.pem
          scp -i key.pem docker-compose.prod.yml ubuntu@$HOST:/home/ubuntu/tinyurl/
          ssh -i key.pem ubuntu@$HOST "cd /home/ubuntu/tinyurl && docker compose -f docker-compose.prod.yml up -d --build"

This is the heartbeat of my project:

Every push triggers the pipeline.
Tests must pass before anything deploys.
The build happens once , and that same build runs in production.

3. Containerization made CI/CD predictable

The biggest win came from using Docker Compose for both local and production setups.

My dev environment runs three containers:

db (Postgres)
fastapi (backend)
nginx (reverse proxy)

And my production setup? Exactly the same- except the compose file uses:

Different environment variables
Mounted SSL certs from Let’s Encrypt
No auto-reload or debugging

Because both stacks share the same Docker config, the CI/CD pipeline doesn’t need special cases or hacks. If it runs locally, it’ll run in CI.

4. Deployment: zero downtime, one command

Once the new image is built and pushed, the EC2 host just pulls and restarts containers with:

docker compose -f docker-compose.prod.yml up -d --build

Nginx handles live traffic, so backend containers can restart without downtime. Since FastAPI and Nginx talk over Docker’s internal network, there’s no need for manual reconfiguration.

That “click → push → deploy” feeling is addictive.

5. Secrets are sacred

The pipeline uses GitHub Secrets to store:

EC2_HOST (server IP or domain)
EC2_SSH_KEY (private key)
POSTGRES_PASSWORD
FASTAPI_SECRET_KEY

No plaintext credentials in the repo, no .env files in commits. That alone made me sleep better at night.

6. What I learned the hard way

Don’t skip tests- failing fast is cheaper than debugging in production.
Don’t rebuild images on the server- build once, deploy the same artifact.
Keep Docker tags consistent- otherwise latest will surprise you.
Automate HTTPS renewal s- my Let’s Encrypt cron job now runs monthly.

These small habits make the pipeline boring- and boring pipelines are the best kind.

7. The result

Now every push to main runs tests, builds containers, and ships a fully reproducible environment to production. No manual steps, no “did I rebuild?” anxiety. Just continuous confidence.

Tech Stack Recap

FastAPI- backend API
PostgreSQL- database
Streamlit- frontend
Nginx- reverse proxy
GitHub Actions- CI/CD
Docker Compose- orchestration

“CI/CD isn’t about speed- it’s about peace of mind.”

This post is part of my TinyURL series- real-world lessons from turning a small FastAPI project into a production-grade service.

How the Browser Works

Kfir — Mon, 20 Oct 2025 03:34:34 +0000

Photo by Jonny Caspari on Unsplash

Most of us use browsers every day, but few understand how they actually work under the hood.

Knowing this helps us write more efficient, predictable web applications — and, honestly, it’s just fascinating.

Let’s take a look at what happens when you open a webpage, step by step.

The Browser Is Almost an Operating System

A modern browser isn’t just a window to the web- it’s a small operating system.

It manages memory, processes, file storage, networking, rendering, JavaScript execution, and a user interface layer.

Browser Capabilities

Networking: Fetch resources over HTTP(S).
Data storage: Cookies, localStorage, IndexedDB.
Execution: Run JavaScript securely in a sandboxed environment.
Rendering: Parse and paint HTML and CSS.
UI: Manage tabs, buttons, and the visual interface.

Each of these parts works together seamlessly- and it all starts with fetching and parsing data.

Behind the Scenes: Browser Architecture

At a high level, a browser consists of:

UI Layer: What you interact with- address bar, tabs, etc.
Data Storage Layer: Where cookies, cache, and site data live.
Browser Engine: The core that coordinates everything. It’s divided into two main parts:
Rendering Engine: Parses HTML and CSS, creates the visual output.
JavaScript Engine: Parses, compiles, and executes JS code.

Examples:

Blink (used by Chrome, Edge, Opera)
WebKit (used by Safari)
Gecko (used by Firefox)

The HTML Journey

When you load a webpage, here’s what happens to the HTML file:

Get raw bytes from the network.
Convert bytes → characters using the correct encoding (e.g., UTF-8).
Tokenize the characters into meaningful pieces — e.g.,

<h1>, <p>, <div>.

Build objects for each element (with parent/child/sibling relationships).
Construct the DOM (Document Object Model) — a live tree structure representing the page.

The DOM isn’t just a static representation- it’s interactive.

JavaScript can modify it, and the browser will update the display accordingly.

Reference: HTML Living Standard

CSS and the Render Tree

CSS follows a similar process:

Parse raw bytes → characters → tokens → nodes.
Build the CSSOM (CSS Object Model)- representing all style rules.
Combine the DOM + CSSOM → Render Tree.
The render tree goes through:

Layout: Calculating sizes and positions.
Painting: Filling pixels on the screen.

The rendering engine handles this- running complex optimizations to repaint only what’s needed.

Reference: CSSOM Specification

JavaScript: The DOM Manipulator

When the browser encounters a <script> tag, it pauses HTML and CSS parsing to execute JavaScript.

That’s because JavaScript can modify the DOM or request additional resources, so the browser needs to know the final structure before continuing.

However, this can block rendering if the CSSOM isn’t ready yet- since the script might depend on styles.

To avoid blocking, we can use:

<script src="app.js" defer></script>

defer tells the browser to continue parsing HTML and execute JS after the DOM is ready.
async executes JS as soon as it’s downloaded, independently of DOM parsing.

Reference: HTML Spec- Script Element

Putting It All Together

Here’s a simplified flow:

HTML → DOM
CSS → CSSOM
DOM + CSSOM → Render Tree → Layout → Paint
JS → Can manipulate DOM/CSSOM → Re-render

Every click, scroll, or animation triggers a careful dance between these systems.

Why It Matters

Understanding how browsers work helps you:

Write non-blocking, performant code.
Optimize paint and layout cycles.
Debug complex rendering or loading issues.
Appreciate just how much happens before your app even loads.

Browsers are one of the most sophisticated pieces of software on your machine- and now you know why.

Further Reading:

MDN: How browsers work

Demystifying Nginx: From Reverse Proxy to Secure Gateway

Kfir — Tue, 14 Oct 2025 02:20:43 +0000

Photo by RealToughCandy.com: https://www.pexels.com/photo/person-holding-a-sticker-with-green-letters-11035538/

When I started building TinyURL , a simple FastAPI + PostgreSQL service for shortening URLs, I thought Nginx would just “serve traffic.” Turns out, it became the most critical piece of my deployment — the gatekeeper that made everything behind it work smoothly and securely.

In this post, I’ll share what I actually learned while wiring Nginx into my FastAPI backend and Streamlit frontend, both running in Docker.

1. Nginx is more than a web server

Before this project, I mostly thought of Nginx as something you use to “host static files.” In reality, it’s a powerful reverse proxy — it sits in front of your app, receives every incoming request, and decides where it should go.

In my stack:

Client → Nginx → FastAPI (backend) → Postgres
                     ↳ Streamlit (UI)

Nginx doesn’t just forward traffic- it also:

Handles HTTPS termination
Adds security headers
Manages WebSocket upgrades for Streamlit
Hides internal services (FastAPI and Postgres) from the public internet

Once I saw that flow working inside Docker Compose, it finally clicked how production apps are structured.

2. Reverse proxying is all about headers and trust

Here’s a simplified version of my production config:

location /api/ {
    proxy_pass http://fastapi:8000;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

These headers are crucial. Without them, FastAPI would have no idea what the original client’s IP or scheme was.

X-Forwarded-Proto in particular tells the backend if the original request came over HTTPS- that’s how FastAPI can generate correct redirect URLs or absolute links.

This part made me appreciate how Nginx “translates” external requests for internal services while preserving client context.

3. HTTPS is not optional

The first time I tried running my app on an EC2 instance, Chrome immediately complained: “Not secure.”

That’s when I integrated Let’s Encrypt with Nginx. The setup was surprisingly simple once I understood what was happening:

The /.well-known/acme-challenge/ path lets Certbot verify domain ownership.
Once validated, Let’s Encrypt issues free SSL certificates.
Nginx then terminates HTTPS using those certs:

ssl_certificate /etc/letsencrypt/live/kg-tiny-url.xyz/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/kg-tiny-url.xyz/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;

I also learned to add a separate HTTP server block just to redirect everything to HTTPS. Small detail, big difference.

4. Security headers are free wins

I wanted to understand what real production configs look like, so I dug into HTTP security headers. Adding these took one line each in Nginx but instantly hardened the app:

add_header Strict-Transport-Security "max-age=31536000" always;
add_header X-Frame-Options "DENY" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Content-Security-Policy "default-src 'self'" always;

You don’t notice them in daily use, but tools like Mozilla Observatory or Lighthouse will thank you.

5. Docker networking just works- if you name things right

Inside Docker Compose, every container gets a DNS name. My proxy_pass http://fastapi:8000 line works because the FastAPI container is literally named fastapi in the YAML file.

That’s how Nginx can find it without any IP addresses.

Once I realized that Docker’s internal DNS makes service discovery effortless, networking suddenly felt simple instead of scary.

6. The moment it all worked

After wiring it all up, I opened my browser to:

https://kg-tiny-url.xyz/ui/

The Streamlit UI loaded. When I shortened a link, it called the FastAPI backend through /api/.

Everything was encrypted, routed, and logged properly- all through Nginx.

That was the moment I understood why every real-world deployment uses a reverse proxy.

7. Final takeaway

Nginx isn’t just a traffic router- it’s the security layer, performance booster, and network translator that makes containerized apps production-ready.

By the end of this project, I didn’t just “set up Nginx.” I learned how the internet actually talks to my code.

If you’re new to Nginx or just want to deepen your understanding, I highly recommend pairing this write-up with this free YouTube tutorial (https://www.youtube.com/watch?v=7VAI73roXaY) for a hands-on introduction, and the Udemy “NGINX Crash Course” (https://www.udemy.com/course/nginx-crash-course/?kw=ngi&src=sac) for a more structured, in-depth path. These two resources helped me grasp concepts like reverse proxying, SSL termination, WebSocket upgrades, and scaling more confidently — and I think they’ll help you too.

Understanding Isolation in PostgreSQL: A Deep Dive into the “I” in ACID

Kfir — Mon, 07 Jul 2025 18:28:31 +0000

Photo by Matheus Viana: https://www.pexels.com/photo/open-locker-in-wooden-locker-room-31220117/

When we talk about PostgreSQL being ACID-compliant, Isolation is the “I” that quietly does a lot of heavy lifting. In my previous articles, we explored Atomicity and Consistency -how PostgreSQL makes sure that transactions either happen fully or not at all, and that the database remains valid. Now it’s time to look at how Isolation keeps transactions from interfering with each other when multiple operations run at the same time.

Isolation sounds simple: each transaction should run as if it’s the only one. But the details can get tricky, especially when different isolation levels come into play. Let’s see what this means, how it works in PostgreSQL, and what to watch out for.

What Isolation Means

In short, Isolation makes sure that the intermediate state of a transaction is invisible to other transactions. If one transaction is in the middle of changing a row, another transaction shouldn’t see a half-finished version of that row.

Without Isolation, you can run into problems like:

Dirty reads : reading uncommitted changes that might get rolled back.
Non-repeatable reads : getting different results when you read the same row twice in a transaction.
Phantom reads : rows appear or disappear when you run the same query again.

PostgreSQL handles this with different isolation levels, each balancing correctness and performance.

PostgreSQL’s Isolation Levels

PostgreSQL supports the standard SQL isolation levels:

Read Uncommitted PostgreSQL actually treats this the same as Read Committed, so dirty reads are never allowed.
Read Committed (default) Each query sees a snapshot of the database taken at the start of that query. Changes committed by other transactions become visible to the next query in the same transaction.
Repeatable Read All queries in the transaction see the same snapshot taken when the transaction starts. You avoid non-repeatable reads, but phantom reads can still happen.
Serializable The strictest level. Transactions run as if they were executed one after another. PostgreSQL uses Serializable Snapshot Isolation (SSI) to make this work and may abort transactions that can’t be serialized.

Let’s See Isolation in Action

Here’s a simple table to experiment with:

CREATE TABLE inventory (
  id SERIAL PRIMARY KEY,
  stock INT
);

INSERT INTO inventory (stock) VALUES (100);

Open two psql sessions: Session A and Session B.

Read Committed: Non-Repeatable Reads

In Session A:

BEGIN;
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

SELECT stock FROM inventory WHERE id = 1;
-- stock = 100

In Session B:

UPDATE inventory SET stock = 50 WHERE id = 1;
COMMIT;

Back in Session A:

SELECT stock FROM inventory WHERE id = 1;
-- stock = 50

The same row gave a different value within the same transaction. This is a non-repeatable read, and it’s allowed in Read Committed.

Repeatable Read: Same Snapshot

Now try Repeatable Read.

Session A:

BEGIN;
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

SELECT stock FROM inventory WHERE id = 1;
-- stock = 100

Session B:

UPDATE inventory SET stock = 30 WHERE id = 1;
COMMIT;

Back in Session A:

SELECT stock FROM inventory WHERE id = 1;
-- stock = 100

This time, the value stays the same because Repeatable Read ensures you always see the same snapshot.

Serializable: Strictest Isolation

With Serializable, PostgreSQL checks whether your transactions could produce different results than if they ran one after the other.

Session A:

BEGIN;
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

SELECT stock FROM inventory WHERE id = 1;
-- 100

UPDATE inventory SET stock = stock - 10 WHERE id = 1;

Session B:

BEGIN;
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

SELECT stock FROM inventory WHERE id = 1;
-- 100

UPDATE inventory SET stock = stock - 20 WHERE id = 1;
COMMIT;

Back in Session A:

COMMIT;
-- ERROR: could not serialize access due to concurrent update

PostgreSQL detects that running these transactions together could lead to inconsistencies, so it rolls one back. Better safe than sorry.

Choosing the Right Level

Read Committed works well for most use cases where short transactions don’t need repeatable reads.
Repeatable Read is useful for consistent reads in longer transactions or reports.
Serializable is the safest but can lead to transaction rollbacks, so you need to handle retries.

Final Thoughts

Isolation is about making sure your transactions don’t see each other’s work half-finished. It’s not something you think about every day- until things go wrong because of subtle race conditions.

Getting Isolation right is key to safe and predictable data in multi-user systems. Now you know what each level does and how PostgreSQL keeps your data consistent even when things get busy.

References

Understanding Durability in PostgreSQL -A Deep Dive into the “D” in ACID

Kfir — Mon, 07 Jul 2025 18:27:07 +0000

Photo by Matheus Viana: https://www.pexels.com/photo/person-on-bike-2372972/

So far in this series, we’ve looked at how PostgreSQL handles Atomicity, Consistency, and Isolation. But what happens after you commit a transaction? What if the power goes out, the server crashes, or someone trips over the plug?

This is where Durability , the final letter in ACID, comes in. Durability means that once a transaction is committed, it will not be lost- no matter what.

What Does Durability Really Mean?

In practical terms, Durability means that when your application gets a COMMIT confirmation, the data is safely stored and recoverable even if the database crashes immediately afterward.

PostgreSQL achieves this with its Write-Ahead Logging (WAL) mechanism. Instead of immediately rewriting table files on disk, PostgreSQL writes changes to a log file first. If the system crashes, PostgreSQL can replay this log to get back to a consistent state.

How Does WAL Work?

Here’s the basic flow:

You run a transaction that changes some data.
PostgreSQL writes the changes to the WAL file on disk.
Only after the WAL record is safely on disk does PostgreSQL acknowledge the COMMIT.

So the WAL acts like a black box flight recorder for your database.

Let’s See Durability in Action

You can see WAL files in action in your data directory. Here’s a simple demo.

First, check your WAL settings:

SHOW wal_level;
SHOW synchronous_commit;

By default, synchronous_commit is on. This means PostgreSQL waits until WAL changes are flushed to disk before confirming the commit.

Test: Crash Recovery (Safe Experiment)

Let’s simulate how WAL protects your data.

Create a test table:

CREATE TABLE durability_test (id SERIAL PRIMARY KEY, data TEXT);

Insert some rows and commit:

INSERT INTO durability_test (data) VALUES ('Important Data 1'), ('Important Data 2'); COMMIT;

Now, force PostgreSQL to checkpoint to flush data to disk:

CHECKPOINT;

If the server crashes after the WAL is written but before data files are updated, PostgreSQL will replay the WAL on startup to make sure your rows are still there.

Of course, don’t yank the power cord — but you can trust that WAL would restore the committed rows.

When Durability Can Be Tuned

Sometimes, applications may want to trade off strict Durability for speed. For example, you can turn off synchronous_commit:

SET synchronous_commit = off;

Now PostgreSQL can acknowledge a commit before the WAL is flushed to disk. If the server crashes immediately, you could lose the last few transactions.

This is faster but obviously less durable — so use it only when you’re okay with that risk (like bulk loads or cache tables).

Real-World Takeaway

Durability is what lets you sleep at night knowing your committed data won’t vanish. PostgreSQL’s WAL and crash recovery have been battle-tested for decades. As long as you keep your WAL files safe (and your disks healthy), your data stays safe too.

References

Understanding Python Memory and Garbage Collection Through Hands-On Experiments

Kfir — Sun, 06 Jul 2025 07:57:08 +0000

Originally published on Medium under the Level Up coding publication.

Python is a high‑level language that takes care of much of the memory management for you. However, understanding how it works under the hood can give you better insights into performance optimization and how to manage your resources efficiently. In this blog post, we’ll explore Python’s memory management and garbage collection (GC) with hands‑on examples. We will focus on three core concepts:

Memory Allocation and Reference Counting
Cyclic References
Using gc to Manage Garbage Collection

Let’s dive in with an experiment‑driven approach using a small Python script that demonstrates these concepts in action.

1. Memory Allocation and Reference Counting

Memory management in Python is primarily handled through reference counting. Every object in Python has a reference count that tracks how many references point to it. When the reference count drops to zero, the object is automatically deleted, and its memory is freed.

Example: Memory Allocation of Simple Objects

import sys

# Create two variables pointing to the same integer object
x = 10
y = 10  # Both x and y point to the same memory location

# Memory address and reference count
print(f"Memory address of x (ID): {id(x)}")
print(f"Memory address of y (ID): {id(y)}")
print(f"Reference count for x: {sys.getrefcount(x)}")

Key Points:

Both x and y point to the same integer object (10), as integers are cached in Python.
The id() function shows that both variables share the same memory address.
sys.getrefcount() reveals that the reference count is greater than 1 because both x and y reference the same object.

After deleting one of the references (del x), the object is still alive because y still holds a reference to the object:

del x
print(f"Reference count after deleting x: {sys.getrefcount(y)}")

Example Output:

Memory address of x (ID): 140705611380560
Memory address of y (ID): 140705611380560
Reference count for x: 2
Reference count after deleting x: 1

As shown, the reference count of the object decreases after x is deleted, but the object is still not destroyed because y still holds a reference to it.

2. Cyclic References and Garbage Collection

Sometimes, objects reference each other in a cycle (e.g., A → B → A), making it impossible for the reference count to reach zero. Python’s garbage collector handles these cases by detecting and cleaning up cyclic references.

Example: Creating a Cycle

class Node:
    def __init__(self, value):
        self.value = value
        self.next = None

# Create a cycle
node1 = Node(1)
node2 = Node(2)
node1.next = node2
node2.next = node1  # This creates a cyclic reference

# Even after deleting both references, the objects are not collected because they still reference each other.
del node1
del node2

Triggering Garbage Collection

To break the cycle and reclaim memory, Python’s garbage collector (gc) can be manually triggered using gc.collect():

import gc

# Manually trigger garbage collection to clean up the cycle
gc.collect()

Key Point:

Python’s GC is able to detect and clean up cyclic references, ensuring that memory is freed even when reference counting can’t handle it.

3. Using `gc` for Custom Garbage Collection

Python provides the gc module to interact with the garbage collector and control the cleanup process. We can check if garbage collection is enabled and even force a collection to clean up unreachable objects. ([medium.com][1])

import gc

print(f"Is Garbage Collection enabled? {gc.isenabled()}")
gc.collect()  # Force garbage collection
print(f"Garbage after collect: {gc.garbage}")

Key Points:

gc.isenabled() checks if garbage collection is enabled in the current Python session.
gc.collect() forces the garbage collection process, which can help clean up cyclic references or unreachable objects.

4. Using `del` for Custom Cleanup

Python allows you to define custom cleanup code using the __del__ method. This method is called when an object is about to be destroyed.

Example: Using `del`

class MyObject:
    def __init__(self, name):
        self.name = name
        print(f"MyObject {self.name} is created!")

    def __del__(self):
        print(f"MyObject {self.name} is being destroyed!")

obj1 = MyObject("Object 1")
obj2 = obj1  # obj2 is another reference to the same object
del obj1     # This will not delete the object, as obj2 still holds a reference
del obj2     # The object is now destroyed because both references are gone

In this example:

When obj1 is deleted, the object is not destroyed because obj2 still holds a reference to it.
When obj2 is also deleted, the object’s __del__ method is called, and the object is destroyed. ([medium.com][1])

Conclusion

Python’s memory management and garbage collection mechanisms are designed to handle most tasks automatically. By understanding reference counting and cyclic references, as well as how to manually trigger the garbage collector, you can ensure that your programs are more efficient and resource‑friendly.

By experimenting with these examples, you gain hands‑on experience in how Python manages memory, how cyclic references are handled, and how to clean up resources using the gc module.

🧠 Key Takeaways

Reference Counting: Tracks object references and deletes objects when they are no longer referenced.
Garbage Collection: Handles cyclic references that reference counting can’t clean up.
__del__ Method: Enables custom cleanup when objects are destroyed.

This knowledge helps you write more efficient and optimized Python code, particularly for resource‑intensive applications.

References

Photo by badr mourafiq

Understanding Consistency in PostgreSQL: A Deep Dive into the “C” in ACID

Kfir — Sun, 01 Jun 2025 22:36:31 +0000

Photo by Matheus Viana: https://www.pexels.com/photo/orange-wall-and-sitting-boy-10216566/

In systems where data correctness is non-negotiable- whether you’re handling user authentication, e-commerce inventory, or hospital patient records- Consistency is the invisible guardrail that ensures the rules of your domain are never broken.

This article explores Consistency , the second principle of ACID. We’ll walk through how PostgreSQL enforces it via constraints, how violations are handled, and what developers need to be mindful of to avoid state corruption in real-world systems.

What Consistency Really Means

Consistency ensures that a transaction brings the database from one valid state to another. That means all defined constraints, rules, and invariants must be satisfied before and after every transaction.

If any part of a transaction would leave the data in an invalid state, PostgreSQL rejects the entire transaction- not just the failing statement-preserving the integrity of your system.

A Schema With Invariants

Let’s return to our simple banking system and define some rules we want PostgreSQL to enforce:

CREATE TABLE accounts (
    id SERIAL PRIMARY KEY,
    name TEXT NOT NULL,
    balance INTEGER NOT NULL CHECK (balance >= 0),
    UNIQUE(name)
);

Here, we’ve defined:

Every account must have a non-null name.
Balances must be zero or greater.
Names must be unique.

These are declarative constraints. PostgreSQL uses them to guarantee that no transaction can violate your domain rules.

Violating Consistency with a Bad Transaction

Say Alice tries to transfer more than she has:

BEGIN;

UPDATE accounts SET balance = balance - 1200 WHERE name = 'Alice';
UPDATE accounts SET balance = balance + 1200 WHERE name = 'Bob';

COMMIT;

If Alice only has 1000, PostgreSQL will raise:

ERROR: new row for relation "accounts" violates check constraint "accounts_balance_check"

At this point, the transaction is marked as failed and must be rolled back:

ROLLBACK;

Result : No changes are applied. This is Consistency at work- the integrity rule (balance >= 0) was violated, so PostgreSQL refused to apply any part of the transaction.

Enforcing Business Logic with Triggers

Not all rules are easily encoded as column constraints. For more complex logic- like age-based restrictions or cross-table validations- we can use triggers.

Example: prevent creating users under age 18.

CREATE OR REPLACE FUNCTION check_age()
RETURNS TRIGGER AS $$
BEGIN
    IF NEW.age < 18 THEN
        RAISE EXCEPTION 'Age must be at least 18';
    END IF;
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER check_age_trigger
BEFORE INSERT OR UPDATE ON users
FOR EACH ROW
EXECUTE FUNCTION check_age();

Now, any INSERT or UPDATE that violates this rule will automatically fail, and the transaction will be rolled back- keeping the system in a consistent state.

Referential Integrity via Foreign Keys

Let’s introduce a transactions table that logs money transfers:

CREATE TABLE transactions (
    id SERIAL PRIMARY KEY,
    from_account INTEGER REFERENCES accounts(id),
    to_account INTEGER REFERENCES accounts(id),
    amount INTEGER NOT NULL CHECK (amount > 0)
);

PostgreSQL ensures that both from_account and to_account actually exist. Attempting to insert a transaction for a non-existent account will fail immediately.

INSERT INTO transactions (from_account, to_account, amount)
VALUES (999, 2, 100);

ERROR: insert or update on table "transactions" violates foreign key constraint

That’s PostgreSQL maintaining consistency via referential integrity.

Consistency in Application Code (Python + psycopg3)

Here’s how consistency violations behave in real-world application code:

import psycopg

conn = psycopg.connect("postgresql://user:pass@localhost/db")

try:
    with conn.transaction():
        with conn.cursor() as cur:
            cur.execute("UPDATE accounts SET balance = balance - 1200 WHERE name = 'Alice'")
            cur.execute("UPDATE accounts SET balance = balance + 1200 WHERE name = 'Bob'")

except Exception as e:
    print(f"Transaction failed: {e}")

If the balance - 1200 fails the CHECK constraint, the entire block is rolled back. You’ll never end up in a partial state where Alice lost money but Bob gained nothing.

Summary of Cases

Constraint violations : Cause immediate rollback of the entire transaction.
Triggers : Allow custom rules that extend beyond column-level checks.
Foreign key violations : Prevent inconsistent references between tables.
Application-level transactions : psycopg3 ensures that rule violations bubble up cleanly, triggering a rollback.

Final Thoughts

Consistency is the safety net that protects your data from logical corruption. PostgreSQL’s constraint system- combined with triggers and foreign keys- ensures that your application’s data model is always honored.

If you’re building systems where correctness matters, you must treat consistency as a first-class design concern. Don’t rely on application code alone to enforce business rules- declarative constraints and transactional integrity are your best allies.

Further Reading:

What Really Happens When You Type `google.com` in Your Browser?

Kfir — Sun, 18 May 2025 14:15:44 +0000

Originally published on Medium under the Level Up coding publication.

Every time you type google.com into your browser’s address bar and press Enter, a complex sequence of events unfolds behind the scenes. This post will break down each step in detail with Python examples and references to official documentation.

1. Domain Name Resolution (DNS Lookup)

Before your browser can connect to Google’s servers, it needs the IP address corresponding to google.com. This process is called DNS resolution.

How it Works:

The browser first checks its DNS cache to see if the domain has been resolved recently.
If not found, it queries the OS’s DNS resolver.
If still unresolved, the OS sends a request to a recursive DNS server (provided by your ISP or a third-party like Google’s 8.8.8.8).
The recursive DNS server queries root name servers → TLD name servers (.com) → Authoritative name servers for google.com.
The authoritative name server provides the IP address (e.g., 142.250.184.14).
The response is cached for future queries.

🔗 Official Docs:

Python Code for DNS Resolution:

import socket

domain = "google.com"
ip = socket.gethostbyname(domain)
print(f"Resolved {domain} to {ip}")

2. Establishing a TCP Connection

Once the IP is known, the browser establishes a TCP connection using the three-way handshake:

SYN: The client sends a TCP packet with the SYN flag set.
SYN-ACK: The server responds with a packet containing SYN and ACK flags.
ACK: The client acknowledges and the connection is established.

🔗 Official Docs:

Python Code for TCP Connection:

import ssl, socket

context = ssl.create_default_context()
sock = socket.create_connection((ip, 443))  # HTTPS uses port 443
secure_sock = context.wrap_socket(sock, server_hostname=domain)
print("TCP connection established with Google")

3. TLS Handshake & Secure Connection

Since Google uses HTTPS, an additional TLS handshake takes place:

Client Hello: The browser sends supported encryption protocols.
Server Hello: The server responds with a chosen encryption algorithm.
Certificate Exchange: The server provides an SSL certificate for verification.
Key Exchange: Both parties establish an encrypted communication channel.

🔗 Official Docs:

Python Code for TLS Handshake:

print(secure_sock.version())  # Print the TLS version used

4. Sending an HTTP Request

Once connected, the browser sends an HTTP request. A standard request for Google’s homepage:

GET / HTTP/1.1
Host: google.com
Connection: close
User-Agent: Mozilla/5.0 (compatible; Chrome)

🔗 Official Docs:

Python Code for Sending an HTTP Request:

request = "GET / HTTP/1.1\r\nHost: google.com\r\nConnection: close\r\n\r\n"
secure_sock.sendall(request.encode())

5. Receiving and Processing the Response

Google’s server responds with an HTTP response, typically a 301 Redirect:

HTTP/1.1 301 Moved Permanently
Location: https://www.google.com/

This instructs the browser to retry the request at https://www.google.com/.

🔗 Official Docs:

Python Code for Receiving Response:

response = b""
while True:
    data = secure_sock.recv(4096)
    if not data:
        break
    response += data
print(response.decode(errors='ignore'))

6. Rendering the Webpage

Once the browser receives the response, it:

Parses the HTML.
Fetches additional resources (CSS, JavaScript, images).
Executes scripts.
Renders the page on the screen.

🔗 Official Docs:

7. Handling Subsequent Requests (Cookies, Caching, CDN)

Cookies: The server might set authentication cookies.
Caching: The browser stores assets for faster loading in future requests.
CDN Requests: Additional requests might be sent to Google’s CDN for assets.

🔗 Official Docs:

Conclusion

When you type google.com and press Enter, a series of sophisticated network processes occur, including DNS resolution, TCP/TLS handshakes, HTTP requests, and webpage rendering. Each step plays a critical role in delivering web pages securely and efficiently.

Want to Try It Yourself?

Run the Python snippets above to see the process in action! 🚀

Understanding Atomicity in PostgreSQL: A Deep Dive into the “A” in ACID

Kfir — Mon, 12 May 2025 14:25:59 +0000

Photo by Thiago Matos : https://www.pexels.com/photo/orange-led-cfl-bulb-2338672/

In production systems that manage critical data- whether financial transactions, user state, or infrastructure configuration- the integrity of state transitions is non-negotiable. That’s where the ACID properties of relational databases come into play.

This article takes a focused look at Atomicity , the first principle of ACID. We’ll analyze how PostgreSQL enforces it, how failures are handled, and what engineers must understand to avoid subtle consistency bugs in real-world systems.

What Atomicity Really Means

Atomicity guarantees that a transaction is all-or-nothing : every operation in the transaction either completes successfully, or none of them do. There is no concept of “partial success.”

Atomicity is enforced at the transaction level, not the statement level. PostgreSQL ensures that even if a failure occurs midway through a transaction, all previous operations in that transaction are automatically rolled back.

For reference, see the official PostgreSQL Transaction Tutorial.

A Simple Transfer Operation

Consider a simplified banking example. We’ll create an accounts table and simulate transferring funds between two accounts:

CREATE TABLE accounts (
    id SERIAL PRIMARY KEY,
    name TEXT NOT NULL,
    balance INTEGER NOT NULL CHECK (balance >= 0)
);

INSERT INTO accounts (name, balance)
VALUES ('Alice', 1000), ('Bob', 1000);

Now, we implement a basic transfer operation using an explicit transaction:

BEGIN;

UPDATE accounts SET balance = balance - 200 WHERE name = 'Alice';
UPDATE accounts SET balance = balance + 200 WHERE name = 'Bob';

COMMIT;

If both statements succeed, the transaction is committed and both updates become permanent.

Simulating a Failure

Now let’s simulate an error that occurs in the second statement:

BEGIN;

UPDATE accounts SET balance = balance - 200 WHERE name = 'Alice';
-- Intentional typo: column name is misspelled
UPDATE accounts SET balnce = balance + 200 WHERE name = 'Bob';

COMMIT;

PostgreSQL will raise an error:

ERROR: column "balnce" does not exist

At this point, the transaction is marked as failed. No further operations are allowed until a rollback is issued:

ROLLBACK;

Although the first UPDATE ran without error, its effect is discarded because the transaction was never successfully committed. This is atomicity in practice.

What If You Don’t Use Transactions?

When operations are issued individually without an explicit BEGIN block, PostgreSQL executes each as its own atomic unit:

UPDATE accounts SET balance = balance - 200 WHERE name = 'Alice';
-- This succeeds

UPDATE accounts SET balnce = balance + 200 WHERE name = 'Bob';
-- This fails

Here, Alice’s balance is reduced, but Bob never receives the funds. This violates our consistency requirements and results in data loss.

Lesson: without explicit transactions, the database cannot enforce atomicity across multiple operations.

Statement-Level Atomicity

PostgreSQL does provide implicit transaction handling for single statements. If a single INSERT, UPDATE, or DELETE statement fails, it is discarded entirely and does not affect the database. However, for multiple operations that must succeed together, atomicity is not guaranteed unless you explicitly wrap them in a transaction.

Relevant documentation: PostgreSQL BEGIN

Constraint Failures and Runtime Errors

PostgreSQL also enforces atomicity in the presence of constraint violations or other runtime errors. For example, suppose we enforce that balances cannot be negative:

ALTER TABLE accounts ADD CONSTRAINT non_negative_balance CHECK (balance >= 0);

Then attempt:

BEGIN;

UPDATE accounts SET balance = balance - 1100 WHERE name = 'Alice';
UPDATE accounts SET balance = balance + 1100 WHERE name = 'Bob';

COMMIT;

Alice only has 1000, so her balance would go negative. The first statement violates the constraint, and the entire transaction is aborted. No changes are applied.

Handling Transactions in Application Code

Here’s how atomicity works in a real-world PostgreSQL client using Python with psycopg3:

import psycopg

conn = psycopg.connect("postgresql://user:pass@localhost/db")

try:
    with conn.transaction():
        with conn.cursor() as cur:
            cur.execute("UPDATE accounts SET balance = balance - 200 WHERE name = 'Alice'")
            cur.execute("UPDATE accounts SET balnce = balance + 200 WHERE name = 'Bob'") # Bug

except Exception as e:
    print(f"Transaction failed: {e}")

In this case, conn.transaction() ensures that the entire block is treated as atomic. When the second query fails, psycopg3 automatically rolls back the transaction. No data is persisted.

Summary of Cases

Single UPDATE : Executed without an explicit transaction block, PostgreSQL treats it as an implicit transaction. It either succeeds or fails as a single atomic operation.
Multiple UPDATEs without BEGIN : When multiple operations are issued individually without wrapping them in a transaction, atomicity is not guaranteed. If one statement succeeds and another fails, partial state changes can persist.
BEGIN / COMMIT with syntax or runtime error : When using an explicit transaction, any error- be it a syntax issue or constraint violation- causes the entire transaction to be rolled back. This ensures atomicity across all enclosed operations.
Using psycopg3 with with conn.transaction(): In application code, using this context manager ensures atomicity. If any exception is raised during the block, psycopg3 automatically rolls back the transaction.

Final Thoughts

PostgreSQL provides strong atomicity guarantees, but they’re only effective when transactions are used intentionally and correctly. Multi-statement operations should always be wrapped in an explicit transaction, and developers must anticipate rollback paths as part of the application’s normal flow.

Failing to do so can result in partial writes, corrupted state, and long-tail data integrity bugs that are difficult to trace.

For more details, refer to the official documentation:

DEV Community: Kfir

From Passive FastAPI Developer to Real FastAPI Engineer- Part 2

1. Why Build a Raw ASGI App?

2. ASGI in 60 Seconds

The ASGI callable signature

3. Step-by-Step: Build a Raw ASGI App

4. Run the App With Uvicorn

5. Understanding the ASGI Scope

6. Understanding receive() Events

7. Understanding send() Events

Start the HTTP response:

Send body:

8. Diagram — The ASGI Lifecycle

9. Compare This With WSGI

10. Quick Exercises

1. Return JSON manually

2. Parse query params manually

3. Print content length

4. Respond in two chunks (streaming)

Wrapping Up: Why You Just Built ASGI by Hand

Official References (Highly Recommended)

ASGI

HTTP / Request Lifecycle

Uvicorn

Starlette (ASGI Toolkit)

FastAPI

WSGI / CGI History

From Passive FastAPI Developer to Real FastAPI Engineer- Part 1: ASGI

Understanding ASGI by Breaking Down an HTTP Request

What is ASGI?

Why Do We Need ASGI?

A Quick Timeline of Request Interfaces

Why WSGI Wasn’t Enough

ASGI’s Core Idea

A Minimal ASGI App (Raw)

HTTP Request Flow in WSGI vs ASGI

WSGI Flow (Sync)

ASGI Flow (Event-Based, Async)

Why ASGI Matters

1. Concurrency

2. WebSockets Support

3. Full-Duplex Communication

4. Protocol Independence

A Tiny Diagram: ASGI in FastAPI

Final Summary

References:

Why I Use curl Instead of Postman: Learning HTTP by Feel

Learning Through the Fingertips

Seeing the Protocol, Not the UI

Discovering More

How curl Fits in Everyday Dev Life

1. Health checks

2. Quick response code check

3. Debugging with headers

4. Testing authentication

5. Sending JSON data

6. Simulating different HTTP verbs

7. Working inside Docker containers

8. Testing redirects and caching

9. Monitoring endpoints continuously

10. Downloading and uploading files

The Terminal Teaches Clarity

Feel the Protocol

Shipping FastAPI Like a Pro: My CI/CD Pipeline for TinyURL

1. CI/CD isn’t about tools- it’s about trust

2. The build pipeline: test early, build once

3. Containerization made CI/CD predictable

4. Deployment: zero downtime, one command

5. Secrets are sacred

6. What I learned the hard way

7. The result

Tech Stack Recap

How the Browser Works

The Browser Is Almost an Operating System

Browser Capabilities

Behind the Scenes: Browser Architecture

The HTML Journey

CSS and the Render Tree

JavaScript: The DOM Manipulator

Putting It All Together

3. Using `gc` for Custom Garbage Collection

4. Using `del` for Custom Cleanup

Example: Using `del`