Forem: Artem

I built a Self-Hosted Solana Payments Library for Django Framework

Artem — Sun, 29 Mar 2026 14:38:30 +0000

I have built a library for the Django framework that simplifies the process of accepting crypto payments for your e-commerce (and other) applications.

django-solana-payments is an open-source Django library for accepting self-hosted Solana payments with automated on-chain verification.

Artemooon / django-solana-payments

A plug-and-play Django library for accepting online payments via the Solana blockchain

Django Solana Payments

A Django library for integrating Solana payments into your project. This library provides a flexible and customizable way to accept Solana payments with support for customizable models, an easy-to-use API, and management commands for processing online payments using the Solana blockchain.

Key Features

Transaction verification and automatic payment confirmation: Monitors the Solana blockchain, verifies incoming transactions, and automatically confirms payments when the expected amount is received.
Multi-token support (SOL and SPL tokens): Configure a list of active payment tokens (for example, SOL and USDC) and the library will use them for pricing and verification flows.
Flexibility and customization: Use your own custom models for payments and tokens to fit your project's needs. Add custom logic using signals or callabacks.
Ease of integration: Provides ready-to-use endpoints that can be used in existing DRF applications, or ready-to-use methods for Django applications that are not part…

View on GitHub

Main Benefits
Package Features
Quick Start
How It Works and Tech Stack
Development Process and Takeaways

It was inspired by libraries such as django-payments, but designed specifically for Solana-based payments and for teams that want a self-hosted, flexible integration.

Main Benefits

No platform fees: You pay only standard blockchain transaction fees.
Fully self-hosted: Everything runs on your own infrastructure.
No third-party dependency: No reliance on external payment gateways or complex webhook management.
Easy integration: Get started in just three steps with Django and DRF.
Token Support: Supports native SOL and any Solana SPL token.
Extensible: Customize models and react to events with Django signals.

Package Features

This package is aimed at developers and companies who want a robust, ready-to-use solution for safely accepting Solana payments inside their own Django infrastructure.

Ready-to-use DRF endpoints: For payment initiation, transfer verification, and payment details.
Customizable models: Integrate with your existing domain models easily.
Signals (Hooks/Callbacks): For processing post-payment business logic.
Management commands: For reconciliation, fund consolidation, and reclaiming rent from token accounts.
Security: Built-in encryption for one-time wallet private keys.

Quick Start

To get started, install the package via pip:

Get Started

pip install django-solana-payments

Then, add it to your INSTALLED_APPS and configure your Solana RPC node in your settings.

See more in the README

How It Works and Tech Stack

The library is built with Python and Django and is packaged as a reusable Django app.

Main technologies used:

Django for the application framework, ORM integration, admin support, management commands, and extension points such as signals
Django REST Framework as an optional extra for ready-to-use API endpoints
solana and solders for blockchain interaction, transaction parsing, wallet/keypair handling, and signature/status checks
httpx for RPC communication
stamina for more resilient retry behavior around network-dependent operations
cryptography for encrypting one-time wallet private keys before storing them

How It Works Internally

The core idea is simple: each payment gets its own one-time wallet.

The flow looks like this:

create a dedicated one-time wallet for a payment
calculate the expected amount for the selected token
watch blockchain activity for that wallet
verify that the received amount matches the expected payment
check the transaction confirmation level
update the payment status in Django
optionally move funds from the one-time wallet to the main wallet
emit Django signals so the host application can react

After a payment is processed, it emits Django signals so you can run your own business logic (like marking an order as paid) directly inside your application.

Development Process and Takeaways

This is my first open source library, and shipping it was a very different experience from building internal product features.

The hardest part was not writing the code itself, but turning a specific implementation into a reusable package that other developers can install, understand, and trust. That meant spending much more time on API boundaries, documentation, examples, contributor experience, test coverage, release flow, and long-term maintainability.

It took real effort to get this project into a shape that feels production-ready. There were many details to think through: payment lifecycle design, one-time wallet handling, blockchain verification flow, extension points with signals and callbacks, safe defaults, and a developer experience that still feels familiar to Django users.

Building it pushed me to apply a more disciplined open source mindset around packaging, documentation quality, compatibility, and public interfaces. That process was challenging, but very valuable.

If you try the library, I would genuinely appreciate your feedback. If something is unclear, missing, or could be improved, I would like to hear it.

And if you want to support the project, please give it a star on GitHub. It helps more people discover the library. Thanks!

View on GitHub and Start Building

AI Wrote It. Your Database Paid for It: How get_object() in DRF Actions Quietly Kills Backend Performance

Artem — Fri, 27 Feb 2026 20:12:22 +0000

A pattern that looks clean, “idiomatic,” and AI-approved:

  @action(detail=True, methods=["put"])
  def close_ticket(self, request, pk=None):
      ticket = self.get_object()
      workflow_service.close_ticket(ticket=ticket, actor=request.user)
      return Response(TicketDetailSerializer(ticket).data)

It works. It ships. Everyone is happy.

Until you profile it.

The trap — the black horse hiding in plain sight — is self.get_object().

In this case self.get_object() does not fetch “a ticket.” It evaluates the entire get_queryset() for that view.

If get_queryset() is built for rich list/retrieve responses, this action may trigger heavy joins/prefetches for data it never uses.

Let's look at this code:

class TicketViewSet(ModelViewSet):
    serializer_class = TicketSerializer

    def get_queryset(self):
        qs = (
            Ticket.objects
            .select_related("requester", "assignee", "project", "project__customer")
            .prefetch_related(
                "labels",
                "watchers",
                "attachments",
                Prefetch("comments", queryset=Comment.objects.select_related("author")),
                Prefetch("events", queryset=TicketEvent.objects.select_related("actor")),
            )
            .annotate(
                comments_count=Count("comments", distinct=True),
                watchers_count=Count("watchers", distinct=True),
                last_activity=Max("events__created_at"),
            )
        )

        # lots of list filters, permissions, tenant scoping, etc.
        return qs

One status update endpoint can suddenly act like a mini-report query.

This is exactly the kind of thing AI-generated backend code often gets wrong: correct behavior, terrible query shape.

How AI Quietly Wrecks DB Performance

AI tools tend to optimize for:

familiar framework patterns
fewer lines
“it works” correctness

They do not reliably optimize for:

action-specific query plans
serializer/query coupling
P95 latency under load
DB memory/IO overhead

So you get “smart-looking” code with hidden query bloat.

The Core Design Trap

One global get_queryset() for all actions:

list needs broad graph
retrieve needs nested graph
close/reopen need maybe 5 columns total

Then @action calls self.get_object(), inheriting the same heavy graph.

Result: a tiny mutation endpoint executes a heavyweight read path.

Why This Is Bad

Over-fetching by default
Loading comments, subscribers, nested relations for a status flip is waste.

Invisible cost
get_object() reads like O(1) logic; actual SQL can be huge.

Wrong serializer for the job
Returning full serializer after a transition forces extra DB reads and serialization time.

Performance regression at scale
These endpoints are often frequent. Query bloat multiplies quickly.

Better Architecture: Explicit Query Methods

Create dedicated query methods for each use case (repository/query-service).

  class HelpdeskTicketRepository:
      def list_queryset(self, user, filters):
          return (
              HelpdeskTicket.objects
              .filter(...)
              .select_related("reporter", "assignee", "department")
              .prefetch_related("subscribers", "comments__author")
          )

      def transition_queryset(self, user):
          return (
              HelpdeskTicket.objects
              .filter(...)
              .only("id", "status", "closed_by_id", "closed_at", "updated_at")
          )

  class HelpdeskTicketViewSet(ModelViewSet):
      def get_queryset(self):
          if self.action in {"close_ticket", "reopen_ticket"}:
              return repo.transition_queryset(self.request.user)
          return repo.list_queryset(self.request.user, self.request.query_params)

      @action(detail=True, methods=["put"])
      def close_ticket(self, request, pk=None):
          ticket = self.get_object()  # now lean query
          workflow_service.close_ticket(ticket, request.user)
          return Response(TicketStatusSerializer(ticket).data)  # lean response

Cons of the “Just Use get_object() in @action” Habit

Couples action performance to unrelated list/retrieve serializer needs
Encourages accidental N+1 or unnecessary prefetches
Makes optimization reactive instead of intentional
Hides query intent from reviewers
Gives a false sense of simplicity while increasing infrastructure cost

AI + Backend Rule You Should Adopt

Use AI to speed up scaffolding.
Never let AI decide your query strategy without review.

Before optimizing @action, ask a more uncomfortable question:

Should this be an @action at all?

In many codebases, @action becomes a dumping ground for “extra endpoints.” It feels convenient. It keeps everything in one place. It looks tidy.

But structurally, it introduces long-term cost.

Why avoiding @action often leads to better architecture

URL surface becomes implicit and harder to navigate

Routes are derived from method names.
There is no explicit URL declaration.
Finding endpoints requires scanning class methods.

That does not scale.

ViewSets grow uncontrollably

A resource ViewSet starts clean: list, retrieve, create, update, destroy

Then comes: close_ticket, reopen_ticket, assign_ticket, approve_ticket, archive_ticket

Now your “resource controller” is a workflow engine.

It violates Single Responsibility Principle

A TicketViewSet should manage CRUD semantics of a Ticket resource.

Workflow transitions are not CRUD.
They are domain commands.

Query shape leakage

As discussed earlier, @action inherits get_queryset() unless you explicitly override behavior.

That means workflow endpoints silently inherit list/retrieve query weight.

A Cleaner Alternative

Instead of:

@action(detail=True, methods=["put"])
def close_ticket(self, request, pk=None):

Prefer:

class CloseTicketView(APIView):
    def put(self, request, pk):
        ticket = Ticket.objects.only("id", "status").get(pk=pk)
        workflow_service.close_ticket(ticket=ticket, actor=request.user)
        return Response(...)

Now:

URL is explicit

Query is explicit

Responsibility is isolated

Class size stays small

Performance behavior is predictable

One class. One action. One purpose.

Final Takeaway

AI won’t save your database from lazy query design.
If your action updates one status and fetches half your model graph, you’ve already lost.

get_object() is not bad. Blind get_object() on heavyweight querysets is.

Design query paths per endpoint. Your DB, latency charts, and cloud bill will all improve.

If you’ve run into this pattern in production, I’d genuinely like to hear about it.

Have you discovered hidden query explosions behind “clean” DRF code?

Share your experience in the comments.

Boys on February 14: Babe, these flowers are for you, let's go to that fancy restaurant. Men on February 14: Okay, I fixed production for the fifth time today, lemme push a few commits to the GitHub as well.

Artem — Sat, 14 Feb 2026 22:28:06 +0000

How developers can cope with pressure while remaining calm and professional

Artem — Fri, 14 Nov 2025 18:43:17 +0000

Let's start with some very real and common situations.

It's 2 AM and you're trying to fix production after another quick release.

Or the customer is rushing you to complete the task, writing every 20 minutes and asking about progress, which prevents you from focusing on the task.

Or the project manager once again reprimands you in a raised voice about incorrectly tracked time or exaggerated estimates in tickets.

All of these are forms of pressure on a person and a test of their stress resistance.

Some people do it consciously, while others do not.

In any case, this results in stress for the developer, unnecessary anxiety, or even burnout.

I have been through this dozens of times myself, and in this article I will try to explain how I minimize the damage from this kind of communication.

First and foremost, remain calm and professional.

Don't respond to pressure with aggression or discontent; this will lead to even greater unpleasantness and will certainly not spare your nerves. Instead, try to look at the situation through the eyes of the other person and don't take anything personally. A good solution would be to agree with the person and say what they want to hear. Do what they want if this is okay for you. This will save you energy and time.

Analyze their behaviour

Try to analyze the situation when you calm down. Maybe this argument was a one-off and won't happen again. Conversely, notice if they use pressure as a means of controlling their employees. Some managers and companies cannot manage their employees except through fear. It also often happens that everything works itself out on its own.

But try not to make too many assumptions. Ask questions and communicate clearly when it's possible to avoid misunderstandings.

Different types of thinking

Don't forget about the significant differences between developers and managers. If your manager is a hard-working developer who doesn't criticize your code for every little thing, you're very lucky, but more often than not, management roles are more stringent in nature.

Keep this in mind when you go to a personal meeting with non-technical people, and try to put work out of your mind and prepare for a bunch of personal questions and answers to them. This can protect you from unexpected situations.

The manager's job is to supervise you. Your job is to develop the product. You have the right not to waste time on empty chatter, to stay away from meetings, and to benefit the company with your brainpower.

Set boundaries, turn off notifications, and cancel meetings when possible. This will help you stay focused and avoid arguments. You can always say you were busy.

Don't hold anything bad in your mind

Distract yourself with something you enjoy, listen to music, do something neutral that will calm you down and take your mind off work.

Most often, you have to accept people as they are and move on.

Take everything as an experience

Usually, after a dozen different conflict situations, you gain experience and understand how to respond to them. You can also always talk about some of the situations during an interview and how you resolved them peacefully.

That's it for today. Stay calm and enjoy programming.

FastAPI & PostgreSQL Sharding: A Step-by-Step Guide (Part 2) - Step-by-Step Implementation

Artem — Sat, 18 Oct 2025 15:17:22 +0000

This is a continuation of my series of articles about horizontal scaling of databases.

In the first part, we discussed these topics in theory, including consistent hashing, the pitfalls of traditional hashing, and the challenges that sharding introduces at the application layer. Check it out if you haven’t already before moving forward.

In this section, we will focus on the practical implementation of PostgreSQL sharding with a FastAPI backend application.

As a demonstration, we'll build a link shortener app to avoid distractions from the business logic and focus more on the infrastructure and concepts of distributed database systems.

This is the repository with the complete code - https://github.com/Artemooon/postgres-shards

Let's start with the infrastructure setup

First, we need to start a local cluster with Postgres instances. For this, we will use Docker.

Let's create a docker template for our single postgres instance

FROM postgres

COPY init_tables.sql /docker-entrypoint-initdb.d

Here we use the latest PostgreSQL image and also copy our SQL script to the /docker-entrypoint-initdb.d directory.

When the container runs for the first time, Postgres automatically runs any .sql files found in /docker-entrypoint-initdb.d.

So when we start our shards this script creates needed tables for us

This is what we have in the init_tables.sql file, we just create a table where we plan to store our URLS.

Later, we will use URL_ID as our key for the hash ring.

CREATE TABLE URL_TABLE 
(
 id serial NOT NULL PRIMARY KEY,
 URL text, 
 URL_ID varchar(5)
);

After you added these files run this command in the directory with your docker template:

docker build -t my-postgres-shard-image .

Then, to create and run the Docker container, run:

docker run --name pgshard1 -p 5434:5432 -d -e POSTGRES_PASSWORD=postgres pgshard

Note: Repeat this command for as many instances in your cluster as you want. Also, ensure that the port on the left side is unique for each instance.

Creating FastAPI app

We will use UV package and project manager to bootstrap our project.

Install uv

pip install uv

Create a new project

uv init sharding-app
cd sharding-app

Add FastAPI and Uvicorn

uv add fastapi uvicorn

This will be the content of our main.py file:

import uvicorn
from fastapi import FastAPI

from routes.url_routes import urls_router

app = FastAPI()


app.include_router(urls_router, prefix="/urls")

if __name__ == "__main__":
    uvicorn.run("main:app", host="localhost", port=5001, reload=True)

Here we define a command to start our application using the Uvicorn server, and we also add a router for our URL endpoints

Then we need to create a connection to our postgres cluster. Since we are using an asynchronous Python framework, it is better to use an async PostgreSQL connection as well. The asyncpg module helps with this.

import asyncpg

db_configs = {
    "5432": dict(user='postgres', password='postgres', database='postgres', host='127.0.0.1', port=5432),
    "5433": dict(user='postgres', password='postgres', database='postgres', host='127.0.0.1', port=5433),
    "5434": dict(user='postgres', password='postgres', database='postgres', host='127.0.0.1', port=5434),
}



def get_db_connector() -> callable:
    connection_cache: dict[str, asyncpg.Connection] = {}

    async def connector(port: str) -> asyncpg.Connection:
        # Create or reuse connection
        conn = connection_cache.get(port)
        if not conn or conn.is_closed():
            conn = await asyncpg.connect(**db_configs[port])
            connection_cache[port] = conn

        return conn

    return connector

Let me explain this code:

This code defines an asynchronous database connection manager for multiple PostgreSQL instances using asyncpg.

db_configs — a dictionary with connection settings for three PostgreSQL servers running on ports 5432, 5433, and 5434.

get_db_connector() — returns a function (connector) that can be used to get a connection for a specific port.

Inside connector(port):

It checks if a connection for that port already exists and is still open.

If not, it creates a new async connection using asyncpg.connect() and caches it in connection_cache.

Then it returns the active connection.

Hash ring

Next, we need to use a hash ring to decide which database instance should handle a given request

from uhashring import HashRing

from db_connection import db_configs

db_hr = HashRing(nodes=list(db_configs.keys()))

We use HashRing from the uhashring library to distribute requests consistently across multiple PostgreSQL instances (running on ports 5432, 5433, and 5434). This ensures that each key is always mapped to the same database node, and when nodes are added or removed, only a minimal portion of keys need to be remapped.

Check out my previous article on consistent hashing, where I explained how hash rings work and why they’re ideal for distributed systems.

Adding endpoints and business logic

import hashlib
import base64
from fastapi import APIRouter, Depends, HTTPException

from db_connection import get_db_connector
from shard_hashing import db_hr

urls_router = APIRouter()


@urls_router.get("/{url_id}")
async def get_url(url_id: str, get_connection=Depends(get_db_connector)):

    db_server_port = db_hr.get(url_id)["hostname"]
    conn = await get_connection(db_server_port)

    try:
        url_data = await conn.fetchrow("SELECT URL, URL_ID FROM url_table WHERE URL_ID=$1", url_id)
    except Exception as e:
        raise HTTPException(status_code=500, detail=f"DB insert failed: {str(e)}")
    finally:
        await conn.close()

    if not url_data:
        raise HTTPException(status_code=404, detail=f"Url with id: {url_id} was not found")

    return {
        "url_id": url_data.get("url_id"),
        "url": url_data.get("url"),
        "server": db_hr.get(url_id)
    }

@urls_router.post("")
async def create_url(full_url: str, get_connection=Depends(get_db_connector)):
    hash_bytes = hashlib.sha256(full_url.encode('utf-8')).digest()

    base64_hash = base64.b64encode(hash_bytes).decode('utf-8')
    url_id = base64_hash[0:5]
    db_server_port = db_hr.get(url_id)["hostname"]

    conn = await get_connection(db_server_port)

    try:
        await conn.execute("INSERT INTO url_table (URL, URL_ID) VALUES($1, $2)", full_url, url_id)
    except Exception as e:
        raise HTTPException(status_code=500, detail=f"DB insert failed: {str(e)}")

    return {
        "url_id": url_id,
        "url": full_url,
        "server": db_hr.get(url_id)
    }

In this final part, we define two FastAPI endpoints that use the hash ring and database connector to distribute and retrieve data across multiple PostgreSQL instances.

GET /{url_id}

This endpoint retrieves a stored URL by its unique url_id.

It uses the hash ring (db_hr) to determine which database node (port) should hold the record for that specific url_id.

It then fetches the connection from the async connection manager (get_db_connector).

Then SQL query retrieves the URL record.

If no record is found, it returns a 404 error; otherwise, it responds with the URL data and the database node info.

POST /

This endpoint creates a new short URL record.

It takes the original full_url, hashes it with SHA-256, and encodes it using Base64, taking the first few characters as a short, unique url_id.

The url_id is then passed through the hash ring to select which PostgreSQL instance will store it.

The URL and its ID are inserted into that database.

Finally, it returns the created record along with the server node info.

When combined, this creates an application that works efficiently with a database cluster and uses consistent hashing to operate on the required databases.

Additional complications

As you saw, sharding adds additional complexity on the application layer by default. You now need to handle this complexity in your code, such as using consistent hashing, managing multiple database connectors, and ensuring proper data distribution across nodes.

Sharding also adds additional costs associated with maintaining multiple databases instead of one.

Testing our API

Let's start our app and perform some requests.

curl --location --request POST 'http://localhost:5001/urls?full_url=https://www.postgresql.org/'

curl --location --request POST 'http://localhost:5001/urls?full_url=https://www.google.com/'

curl --location --request POST 'http://localhost:5001/urls?full_url=https://www.dev.to/'

This will create new URLs in our database cluster. When creating new records, you may see a different server in the server information object because we pass the unique url_id to the hash ring, which returns the server responsible for that hash.

When fetching a full URL by url_id, it will always be retrieved from the same server, since the hash ring consistently maps that url_id to the same node.

curl --location --request GET 'http://localhost:5001/urls/0OGWo'

Short demo

Conclusion

In this tutorial, we built a minimal working FastAPI application that uses database sharding by combining a hash ring for consistent key distribution and a connection manager for async PostgreSQL access. With this application, you now have a basic template and understanding of how horizontal database scaling works.

FastAPI & PostgreSQL Sharding: A Step-by-Step Guide (Part 1) - Theory

Artem — Mon, 06 Oct 2025 09:39:35 +0000

In this article series, I'll share my experience with the database sharding using PostgreSQL and FastAPI.

This series consists of two articles. In the first one, I'll cover the theoretical concepts behind sharding, including consistent hashing and other common pitfalls in distributed systems. In the second article, I'll showcase a practical FastAPI application that works with PostgreSQL shards.

The purpose of this article is to provide a basic understanding of how distributed databases work and the complexities they introduce into the system.

What is sharding?

Sharding, or horizontal database partitioning , is the process of distributing your your system's data across multiple physical servers (called shards) that together form a cluster.

Do we really need sharding?

Before we start I need to say that I did not have experience working with sharding in production systems (and perhaps you too won't have to work with sharding in production) and this is totally fine, as this optimization technique is an extreme measure in my opinion. I recommend to avoid sharding in production applications, because there are others effective optimizations mechanism such as: indexing, partitioning, replication, denormalization and queries optimization.

Sharding is really required when you are dealing with the billions of rows in a single table and you can not optimize it inside one physical server, then you starting to spawn multiple database server and group them into the cluster.

With the horizontal partitioning, you can distribute the data across multiple smaller, cheaper servers (which is not really possible when you have a single big instance), this makes your system more resilent as well.

Also sharding can help with the geographical distribution, for example, user data from Europe can live in a European shard, and user data from the US can be in a US shard - reducing latency and improving compliance with regional data regulations.

Hashing and consistent hashing

We need to understand how consistent hashing works before moving forward. If you know how the regular hashing works it uses a hash function, that accept arbitrary value and returns an integer.

Example: hash_function("python") = 2393

Now, imagine you have 4 database shards and you add a new user to them, then we can use this integer to locate needed DB instance. As we have a fixed number of shards we use modular of shards amount in our case is 4.

shard = hash_function(user_id) % 4

This will work fine until one of your shard is removed or added. Let's add a new shard, now we have 5 shards in total.

shard = hash_function(user_id) % 5

Now all our users across 4 shards are lost their hash value, which means if you will try to get a user with id that was placed to some instance, this instance number will change and you will not able to locate this user, because the same user ID now points to a different shard.

Consistent hashing was invented to solve this problem. In this method we use a circle (usually it called ring), where we place our database servers at different positions around the ring.

The picture shows: a consistent hashing ring where each server owns a portion of the hash space across the ring.

Let's look at this example:

[0 - - - - - - - - - - - - - - - - - - - 360)
 ^ server A      ^ server B      ^ server C

User id 1 hashed between A and B, we store it in B

User id 2 hashed between B and C, we store it in C

Now we add server D

[0 - - - - - - - - - - - - - - - - - - - 360)
 ^ server A    ^ server D  ^ server B  ^ server C

Only the keys between A and B moved to D. Everything else remains on the same servers.

User id 1 originally hashed between A and B stored on B, but if its hash actually lies between A and D it now maps to D.

User id 2 hashed between B and C, we store it in C.

So minimal resharding still happens , only the keys belonging to the neighboring segment are reallocated, instead of having to rehash and redistribute all data across all servers like in traditional hashing.

Loss of traditional ACID transactions across shards

When you split data across the multiple shards, familiar ACID transaction system is not available. Operations that need to update data across multiple shards can't rely on the database's built-in transaction guarantees.

You either need to:
Implement distributed transactions (with two-phase commits or custom coordination), which adds extra complexity and slows down the transaction commit.

Move toward eventual consistency.

Increased application complexity

With the sharding you application queries logic become harder.
You might need to handle cross shard joins, when you need to access data from different shard for single query
Manage shard logic and fallback logic when rebalancing happens
More complex and expensive deployment and backups collection

In many cases, scaling vertically (and apply optimization techniques for instance), might be cheaper and simpler.

Conclusion

Now you know what consistent hashing and horizontal database partitioning (also known as sharding) are. We've also discussed the complexity of horizontally scaled systems and some of the pitfalls they introduce.

In part two, we'll explore a practical implementation using FastAPI and PostgreSQL.

A Design Pattern Every Python Developer Should Know

Artem — Mon, 29 Sep 2025 16:25:32 +0000

Today we will look at the very useful design pattern in the modern Python development.

Meet The Template method pattern

The Template Method is a design pattern that gives you a master plan for an algorithm. Think of it like a recipe with some specific steps left blank. The main recipe (the "template") is fixed, so you can't change the overall order of the steps. However, you can fill in the blank parts with your own custom code.

The problem template method solves

Let's take the real life problem. Imagine you are building a Crawler IP's Management Service responsible for securely identifying incoming requests from known search engine bots (Applebot, Bingbot, Googlebot, etc.) to improve SEO performance of your app. For each specific bot, the system must perform a sequence of standard steps to fetch and cache its valid list of IP addresses:

Check Cache: Look up the IP list using a bot-specific key in the cache storage.

Fetch Data: If the cache is empty, request the data from the bot's API URL.

Process Data: Extract the actual list of IPv4 and IPv6 addresses from the API response format.

Save Cache: Store the resulting IP list for a set duration.

The initial implementation involves creating a separate class for every bot (e.g., AppleCrawlersService, DuckDuckGoCrawlersService).

class DuckDuckGoCrawlersService:
    """
    A standalone service for managing DuckDuckGo bot IPs.
    This class also contains all the logic, further demonstrating duplication.
    """
    _cache_key = "duckduckgo_bot"
    _ips_list_url = settings.DUCKDUCK_BOT_IPS_URL

    def _extract_ips_from_api_response(self, data):
        """Extracts the list of IPs from the DuckDuckGo API response."""
        content = data.content
        if not content:
            logger.warning(f"No data available to extract IPs for key {self._cache_key}")
            return []

        processed_ips = []
        for line in content.splitlines():
            if line.startswith("- "):
                # Remove '-' and all spaces
                cleaned_line = re.sub(r"[-\s]", "", line)
                processed_ips.append(cleaned_line)
        return processed_ips

    # --- THE DUPLICATED LOGIC STARTS HERE ---

    def _fetch_ips(self, url: str):
        http_client = MockHTTPClientBase(api_base_url=url, api_secret="")
        response = http_client.make_request()
        logger.info(f"Fetched IPs with key: {self._cache_key}")
        return response.content

    def _get_ips_from_cache(self, key: str):
        logger.info(f"Getting crawlers ips from cache: {key}")
        return cache.get(key)

    def _save_ips_to_cache(self, key: str, ip_list: list):
        cache.set(key, ip_list, settings.DEFAULT_CRAWLERS_CACHE_TIMEOUT)
        logger.info(f"Saved crawlers IPs to cache with key: {key}")

    def get_ips_list(self) -> list[str]:
        """
        This entire method is duplicated from the other service classes.
        """
        ips = self._get_ips_from_cache(self._cache_key)
        if ips:
            return ips
        urls = self._ips_list_url if isinstance(self._ips_list_url, list) else [self._ips_list_url]

        with concurrent.futures.ThreadPoolExecutor() as executor:
            responses = list(executor.map(self._fetch_ips, urls))

        ips = list(chain.from_iterable(self._extract_ips_from_api_response(resp) for resp in responses))
        self._save_ips_to_cache(self._cache_key, ips)
        return ips

    # --- DUPLICATED LOGIC ENDS HERE ---


class BingCrawlersService:
    """
    A standalone service for managing Bingbot IPs.
    This class is nearly identical to the Apple service.
    """
    _cache_key = "bingbot"
    _ips_list_url = settings.BINGBOT_IPS_URL

    def _extract_ips_from_api_response(self, data):
        """Extracts the list of IPs from the Bingbot API response."""
        ip_addresses = []
        prefixes = data.get("prefixes", [])
        for prefix in prefixes:
            if settings.CRAWLERS_IP_V4_PREFIX in prefix:
                ip_addresses.append(prefix[settings.CRAWLERS_IP_V4_PREFIX])
            elif settings.CRAWLERS_IP_V6_PREFIX in prefix:
                ip_addresses.append(prefix[settings.CRAWLERS_IP_V6_PREFIX])
        return ip_addresses

    # --- THE DUPLICATED LOGIC STARTS HERE ---

    def _fetch_ips(self, url: str):
        http_client = MockHTTPClientBase(api_base_url=url, api_secret="")
        response = http_client.make_request()
        logger.info(f"Fetched IPs with key: {self._cache_key}")
        return response.content

    def _get_ips_from_cache(self, key: str):
        logger.info(f"Getting crawlers ips from cache: {key}")
        return cache.get(key)

    def _save_ips_to_cache(self, key: str, ip_list: list):
        cache.set(key, ip_list, settings.DEFAULT_CRAWLERS_CACHE_TIMEOUT)
        logger.info(f"Saved crawlers IPs to cache with key: {key}")

    def get_ips_list(self) -> list[str]:
        """
        This entire method is duplicated from the Apple service class.
        """
        ips = self._get_ips_from_cache(self._cache_key)
        if ips:
            return ips
        urls = self._ips_list_url if isinstance(self._ips_list_url, list) else [self._ips_list_url]

        with concurrent.futures.ThreadPoolExecutor() as executor:
            responses = list(executor.map(self._fetch_ips, urls))

        ips = list(chain.from_iterable(self._extract_ips_from_api_response(resp) for resp in responses))
        self._save_ips_to_cache(self._cache_key, ips)
        return ips

    # --- DUPLICATED LOGIC ENDS HERE ---

This works totally fine! But now imagine if you need to add a new crawler parser in the system or change anything in the existing logic for crawlers fetching. Then you need to copy paste your code, create new classes or change existing working code, this approach is error prone and takes additional efforts.

Now look at the code again, do you see any common logic on these classes?

The methods are the same across all crawlers services: _fetch_ips(), _get_ips_from_cache(), _save_ips_to_cache()

And these might be different implementation per class: _extract_ips_from_api_response(), ips_list_url, cache_key

We can create a new abstract class and implement all common methods there and also mark unique details as abstract methods.

class CrawlersServiceABC(ABC):
    @property
    def cache_key(self) -> str:
        """
        The name of the key with which to associate the cached list of crawlers IPs

        Returns:
             str: A name of the key for the cache
        """
        raise NotImplementedError

    @property
    def ips_list_url(self) -> list | str:
        """
        The URL of the resource that the _fetch_ips() method uses to get IP addresses

        Returns:
             str: URL of the resource
        """
        raise NotImplementedError

    @abstractmethod
    def _extract_ips_from_api_response(self, data: dict | requests.Response) -> list[str]:
        """
        Extracts the list of IPs from the response provided by resource

        Returns:
             list[str]: A list of IP addresses associated with the crawler
        """
        raise NotImplementedError

    def _fetch_ips(self, url: str) -> dict | requests.Response:
        http_client = HTTPClientBase(api_base_url=url, api_secret="")

        response = http_client.make_request()
        logger.info(f"Fetched IPs with key: {self.cache_key}")

        return response.content

    def _get_ips_from_cache(self, key: str):
        logger.info(f"Getting crawlers ips from cache: {key}")
        return cache.get(key)

    def _save_ips_to_cache(self, key: str, ip_list: list):
        cache.set(key, ip_list, settings.DEFAULT_CRAWLERS_CACHE_TIMEOUT)
        logger.info(f"Saved crawlers IPs to cache with key: {key}")

    def get_ips_list(self) -> list[str]:
        """
        Single public method that is an entry point for the client's code.
        Either it makes a request to a resource that contains a list of crawlers IPs
        or takes a list of IPs from the cache

        Returns:
             list[str]: A list of IP addresses associated with the crawler
        """
        ips = self._get_ips_from_cache(self.cache_key)
        if ips:
            return ips
        urls = self.ips_list_url if isinstance(self.ips_list_url, list) else [self.ips_list_url]

        # Use ThreadPoolExecutor to fetch IPs concurrently
        with concurrent.futures.ThreadPoolExecutor() as executor:
            responses = list(executor.map(self._fetch_ips, urls))

        # Extract IPs from all responses
        ips = list(chain.from_iterable(self._extract_ips_from_api_response(resp) for resp in responses))
        self._save_ips_to_cache(self.cache_key, ips)
        return ips

Do not pay much attention to the details, this code might a bit complicated, but the main part here is the get_ips_list() method.

This is our template method. It defines the fixed algorithm skeleton. You should generally not redefine this in subclasses.

Updated subclasses look like this:

class AppleCrawlersService(CrawlersServiceABC):
    _cache_key = "applebot"
    _ips_list_url = settings.APPLEBOT_IPS_URL

    def _extract_ips_from_api_response(self, data):
        ip_addresses = []
        prefixes = data.get("prefixes", [])

        for prefix in prefixes:
            if settings.CRAWLERS_IP_V4_PREFIX in prefix:
                ip_addresses.append(prefix[settings.CRAWLERS_IP_V4_PREFIX])
            elif settings.CRAWLERS_IP_V6_PREFIX in prefix:
                ip_addresses.append(prefix[settings.CRAWLERS_IP_V6_PREFIX])

        return ip_addresses

    @property
    def cache_key(self) -> str:
        return self._cache_key

    @property
    def ips_list_url(self) -> str:
        return self._ips_list_url

class DuckDuckGoCrawlersService(CrawlersServiceABC):
    _cache_key = "duckduckgo_bot"
    _ips_list_url = settings.DUCKDUCK_BOT_IPS_URL

    def _fetch_ips(self, url: str):
        try:
            response = requests.get(self._ips_list_url)
            response.raise_for_status()
            logger.info(f"Fetched IPs with key: {self.cache_key}")
            return response
        except requests.RequestException as e:
            logger.warning(f"Error fetching IPs with key {self.cache_key}: {e}")

    def _extract_ips_from_api_response(self, data):
        if not data or not data.text:
            logger.warning(f"No data available to extract IPs for key {self.cache_key}")
            return []

        content = data.text
        processed_ips = []

        for line in content.splitlines():
            if line.startswith("- "):
                # Remove '-' and all spaces
                cleaned_line = re.sub(r"[-\s]", "", line)
                processed_ips.append(cleaned_line)

        return processed_ips

    @property
    def cache_key(self) -> str:
        return self._cache_key

    @property
    def ips_list_url(self) -> str:
        return self._ips_list_url

Now each of them must implement _extract_ips_from_api_response() method.

But common methods _get_ips_from_cache() and _save_ips_to_cache() are taken from CrawlersServiceABC

All common logic is located directly in the CrawlersServiceABC abstract class, child classes manage the concrete logic of abstract methods, the entire algorithm is built using the template method. Finally, template method can be called by the client code.

apple_crawler_service = AppleCrawlersService()
duck_duck_go_crawler_service = DuckDuckGoCrawlersService()

apple_crawler_service.get_ips_list()
duck_duck_go_crawler_service.get_ips_list()

You might notice that we also redefined _fetch_ips() method for the DuckDuckGoCrawlersService, however it is not abstract method.

These methods are called hooks. Hooks are methods that have a default, common implementation in the base class, but which can be optionally overridden by a subclass to provide specific behavior.

We can do the same with the cache_key, ips_list_url properties if we want to.

So why is it important for Python devs?

Now that we've learned a new design pattern, we need to make sure we know how to recognize when someone else used it. Recognizing the Template Method pattern makes it much easier to understand someone else's code.

The most ubiquitous example of the Template Method pattern in Python is found in the Magic Methods (or "Dunder" methods, like __init__, __new__, __str__, etc.).

When you implement a class, you often override these built-in methods to customize how your object behaves. The secret here is that Python executes your code the same way as template method executes the code of your hooks in subclasses.

The process of creating an object in Python is one of the clearest examples of the Template Method pattern being executed by the interpreter itself.

The Template Method (the overall instantiation process) dictates the fixed order: __new__ then __init__. The Primitive Operation that developers override to inject their unique setup logic is __init__.

class BaseObject:
    # __new__ is part of the FIXED TEMPLATE. It creates the object.
    def __new__(cls, *args, **kwargs):
        print("TEMPLATED STEP 1: Allocating memory and creating raw object instance.")
        instance = super().__new__(cls)
        return instance

class UserProfile(BaseObject):
    # __init__ is hook we override.
    # We provide the useful logic for us here.
    def __init__(self, username, is_admin=False):
        print(f"TEMPLATED STEP 2: Running initialization logic for UserProfile('{username}')")
        self.username = username
        self.is_admin = is_admin
        print("TEMPLATED STEP 2 COMPLETE: Object configuration finished.")

# When we call the constructor, the Template Method (instantiation) runs:
print("--- Starting UserProfile(name='Alice') ---")
user = UserProfile(username="Alice")
# The final step of the template returns the initialized object.

print(f"Resulting object: {user.username}, Admin: {user.is_admin}")

Another real world example is DRF's views system design.

Remember how you manage your views using DRF's generic views?

Here is the code of the ListModelMixin class and the list() method is implemented as a template method.

class ListModelMixin:
    """
    List a queryset.
    """
    def list(self, request, *args, **kwargs):
        queryset = self.filter_queryset(self.get_queryset())

        page = self.paginate_queryset(queryset)
        if page is not None:
            serializer = self.get_serializer(page, many=True)
            return self.get_paginated_response(serializer.data)

        serializer = self.get_serializer(queryset, many=True)
        return Response(serializer.data)

When you create your custom view like this one:

class PostListView(GenericAPIView, ListModelMixin):
    # Primitive Operation 1: Tell the Template which data to use.
    queryset = Post.objects.filter(published=True)

    # Primitive Operation 2: Tell the Template how to structure the data.
    serializer_class = PostSerializer

    # Template Method Hook: The base ListModelMixin.list() method calls
    def get(self, request, *args, **kwargs):
        return self.list(request, *args, **kwargs)

# The list() method (inside ListModelMixin) is the Template:
# 1. Calls get_queryset() (which uses our Primitive Operation: queryset)
# 2. Checks for pagination
# 3. Calls get_serializer() (which uses our Primitive Operation: serializer_class)
# 4. Returns Response

You are using a template method pattern without even noticing it, Django create the skeleton of the algorithm for you and you just override the hooks.

Conclusion

The Template Method pattern solves code duplication by defining a fixed algorithm in a base class, forcing subclasses to only implement the unique steps. Python developers may use this pattern implicitly in their code, but understanding The Template Method makes it much easier to understand other people's code and helps create a flexible architecture.

Django + PgBouncer in Production: Pitfalls, Fixes, and Survival Tricks

Artem — Sun, 14 Sep 2025 16:27:05 +0000

In this article I will tell you about my experience of using PgBouncer with the Production Django application, and how it worked for us and what difficulties we met.

First, I’ll explain why we needed a connection pooler like PgBouncer and how it helps solve common database connection overhead problems. After that, I will guide you through our installation process and share our experience using it in a production environment, including the specific problems we faced and the solutions we implemented

Why did we need to add PgBouncer?

Our backend wasn’t constantly flooded with users, but during ad campaigns we saw huge traffic spikes that created hundreds of open connections to PostgreSQL instance. This connection overhead was a significant bottleneck. So, we decided to offload the connection burden from the database by adding a connection pooler.

To understand the problem, we first need to look at how PostgreSQL handles client connections. Every time a new connection is established, the following occurs:

TCP Handshake: A three-way handshake between the client (our Django app) and the database to establish a connection.
If TLS/SSL is enabled, another handshake to secure the connection
Authentication, the database authenticates the user's credentials

In addition to these steps, each open connection consumes a certain amount of memory and CPU resources. This can add an unwanted extra load on the database server. Furthermore, if the number of connections exceeds the configured maximum, new connection requests can fail.

PgBouncer's core job here is to maintain a fixed number of "hot" connections to the database. This effectively solves the problem by allowing the expensive, three-step connection process that I described above, to happen only once for each connection in the pool.

When our Django app needs a connection, it talks to PgBouncer, which immediately provides a ready-to-use connection from its pool. After the query or transaction is finished, PgBouncer immediately returns the connection to the pool, ready for the next client to use.

You can always check the max_connections limit for your specific database (for example, on Amazon RDS). If you can predict a fairly fixed and manageable amount of connections, you might not need to add the complexity of a connection pooler to your architecture. However, in our case, the unpredictable traffic spikes made a connection pooler a necessity.

Installation and configuration process

Installing and setting up PgBouncer is pretty straightforward, you can use official docker image or build it directly from sources.

We chose to use Docker container as we use ECS for our deployment process.

The core of PgBouncer's setup is pgbouncer.ini configuration file or if you use Docker container you can specify file with the environment variables. These are the parameters we used:

PGBOUNCER_LISTEN_ADDRESS=*
PGBOUNCER_POOL_MODE=transaction
PGBOUNCER_PORT=6432
PGBOUNCER_MAX_CLIENT_CONN=1000
PGBOUNCER_DEFAULT_POOL_SIZE=80
PGBOUNCER_MIN_POOL_SIZE=30
PGBOUNCER_AUTH_TYPE=md5
POSTGRESQL_PASSWORD=<YOUR_PASSWORD>
POSTGRESQL_HOST=<YOUR_HOST>
POSTGRESQL_PORT=<POSTGRES_PORT>
POSTGRESQL_USERNAME=<POSTGRES_USERNAME>
POSTGRESQL_DATABASE=<POSTGRES_DATABASE>
PGBOUNCER_DATABASE=<PGBOUNCER_DATABASE>

Here is the overview of interesting parameters

PGBOUNCER_LISTEN_ADDRESS: Specifies the network interface PgBouncer listens on for incoming client connections. We set it to *, which means it listens on all available interfaces. This is not recommended to use * unless you have correctly configured your security groups on a platform like AWS to restrict incoming traffic. For better security, you should use a more specific address like the private IP of the host or a specific network interface.

PGBOUNCER_POOL_MODE: A setting that defines how PgBouncer manages its connections. We chose transaction mode, as it reuses connections after each transaction. Detailed about it below.

PGBOUNCER_MAX_CLIENT_CONN: The maximum number of total client connections your PgBouncer instance will accept.

PGBOUNCER_DEFAULT_POOL_SIZE: The number of "hot" connections PgBouncer maintains to the database for each user and database pair. Set this value to your usual connections amount.

PGBOUNCER_MIN_POOL_SIZE: The minimum number of connections PgBouncer will maintain in the pool, even during periods of low activity. This helps reduce latency by keeping connections ready.

PGBOUNCER_AUTH_TYPE: The authentication method PgBouncer uses to verify clients.

POSTGRESQL_HOST, POSTGRESQL_PORT, POSTGRESQL_USERNAME, POSTGRESQL_DATABASE: These parameters tell PgBouncer how to connect to the actual PostgreSQL database. They are the credentials for the database itself, not the client.

Security note: you should make PgBouncer accessible only from within your trusted network (preferably only for the backend instance) and treat access to it with the same level of caution as you would a direct connection to your database.

The difficult choice of the pool mode

There are 3 types of pool mode for PgBoucner: Session mode, Transaction mode, Statement mode.

Statement mode is the most aggressive and performant pooling mode, but it's the least compatible with most applications because it breaks transactions support, on the other hand session mode is the most compatible pooling mode for the usual application, but it's the least performant, however it still gives you the advantage of "hot" tcp connections pool. Transaction mode allocates a connection per transaction and is somewhere in the middle of the three pooling modes.

There is no single "best" mode; the right choice depends on your application's unique needs. Transaction mode is the standard for most Django apps, but if your app relies on session-level features, session mode is a necessary compromise.

So we started with session mode on our dev server, then used it in production and confirmed everything was stable. Afterward, we enabled transaction mode on production, which required some tricks to get working.

The tricks we used to solve transaction mode issues and make our Django application reliable

In this section, I am describing complexities with the PgBouncer and providing solutions for them.

Migrations

When running Django migrations through PgBouncer in transaction pooling mode, some operations fail because they require a single session with an open transaction. For example:

CREATE INDEX CONCURRENTLY or DROP INDEX CONCURRENTLY
These statements are disallowed inside a transaction block, but Django wraps migrations in transactions by default.
Long‐running schema changes (e.g., adding constraints) may get interrupted because transaction pooling swaps connections between queries.
Advisory locks (pg_advisory_lock) and similar session-based features also fail under transaction pooling.

To solve it we run migrations against PostgreSQL directly, not through PgBouncer:

# set PG_BOUNCER_HOST and PG_BOUNCER_PORT to none to run migration directly against Postgresql
PG_BOUNCER_HOST= PG_BOUNCER_PORT= python manage.py migrate

Search path

We used a custom schema for storing our tables and specified it with the search path in the database connection settings

We used a custom schema for storing our tables and specified it with the search path in the database connection settings.

When PgBouncer is running in transaction pooling mode, every query may use a different backend connection. That means any session-level settings (like search_path, SET ROLE, SET TIMEZONE, etc.) do not persist across queries.

This works fine when Django talks directly to Postgres, because each session is pinned to a single connection.
But with PgBouncer in transaction pooling, the search_path setting disappears as soon as the transaction ends. The next query may land on a different connection that doesn’t know about your search_path override.

This may lead to:

A migration that tries to create a table may end up running in the default public schema, ignoring your schema defined in the search path.
You end up with “phantom” tables in public, while your app is looking in your defined schema.

We fixed it by making our non-default schema the actual default schema, and stopped relying on search_path:

We altered the database schema setup so that our custom is the default. Using ALTER ROLE <db_user> SET search_path = <your_schema>;
Then we removed the OPTIONS → -c search_path=cryptonary_wp2 entirely from Django’s database settings.
Then we migrated tables from public schema to our custom schema using sql script

Disabling server side cursor

Django can stream large querysets efficiently by using server-side cursors under the hood — for example, when you call .iterator(), rows are fetched incrementally instead of all being loaded into memory at once.

However, PgBouncer in transaction pooling mode breaks this.

Server-side cursors depend on the connection being pinned to the same backend for the lifetime of the cursor.

Transaction pooling reuses connections between queries, so as soon as the transaction ends, the cursor is lost.

In practice, this results in errors like cursor does not exist when iterating, or worse, inconsistent data reads.

For example, we periodically saw this exception when browsing the Django admin panel:

InvalidCursorName: cursor "_django_curs_140116399986368_sync_1" does not exist

To avoid this, Django has a built-in option for the database connection:

DATABASES = { "DISABLE_SERVER_SIDE_CURSORS": True, }

With this setting enabled, Django’s .iterator() will fetch the entire result set into backend memory. That means your memory usage can grow significantly when iterating over large querysets, which may affect your application performance.

You could use an extra direct connection to the database if you need server side cursors benefits and then use the direct connection for those queries:

YourModel.objects.using('direct_db_connection').filter().iterator()

Reliability: Fallback from PgBouncer to Postgres

We also added a simple reliability check in our settings to make sure the application can still connect even if PgBouncer is down or misconfigured.

try:
    if PG_BOUNCER_HOST and PG_BOUNCER_PORT:
        conn = psycopg2.connect(
            dbname=os.environ.get("POSTGRES_NAME"),
            user=os.environ.get("POSTGRES_USER"),
            password=os.environ.get("POSTGRES_PASSWORD"),
            host=PG_BOUNCER_HOST,
            port=PG_BOUNCER_PORT,
            connect_timeout=2,
        )
        conn.close()
        DB_HOST = PG_BOUNCER_HOST
        DB_PORT = PG_BOUNCER_PORT
    else:
        raise OperationalError("No PgBouncer host set")

except OperationalError:
    DB_HOST = POSTGRES_HOST
    DB_PORT = POSTGRES_PORT

This provides a graceful degradation path: the app may lose PgBouncer’s pooling benefits temporarily, but it will stay online and functional.

I think that was a lot, right? Do you still want to connect PgBouncer to your Django application or CONN_MAX_AGE saves the day?

Conclusion

PgBouncer is the right tool to help scale your Postgres app when the number of database connections becomes an issue. Keep in mind that while adding PgBouncer introduces additional complexity for your team, careful setup, monitoring, and tuning should improve your app’s performance.

That said, PgBouncer should only be introduced if you really need it. It adds complexity, hidden caveats (like migrations, search path resets, server-side cursors), and operational costs. If you do adopt it, make sure you fully understand these trade-offs and adjust your Django configuration accordingly.

Forem: Artem

I built a Self-Hosted Solana Payments Library for Django Framework

Artemooon / django-solana-payments

A plug-and-play Django library for accepting online payments via the Solana blockchain

Django Solana Payments

Key Features

Table of Contents

Main Benefits

Package Features

Quick Start

Get Started

How It Works and Tech Stack

How It Works Internally

Development Process and Takeaways

AI Wrote It. Your Database Paid for It: How get_object() in DRF Actions Quietly Kills Backend Performance

How AI Quietly Wrecks DB Performance

The Core Design Trap

Why This Is Bad

Better Architecture: Explicit Query Methods

Cons of the “Just Use get_object() in @action” Habit

AI + Backend Rule You Should Adopt

Final Takeaway

Boys on February 14: Babe, these flowers are for you, let's go to that fancy restaurant. Men on February 14: Okay, I fixed production for the fifth time today, lemme push a few commits to the GitHub as well.

How developers can cope with pressure while remaining calm and professional

FastAPI & PostgreSQL Sharding: A Step-by-Step Guide (Part 2) - Step-by-Step Implementation

Let's start with the infrastructure setup

Creating FastAPI app

Hash ring

Adding endpoints and business logic

Additional complications

Testing our API

Short demo

Conclusion

FastAPI & PostgreSQL Sharding: A Step-by-Step Guide (Part 1) - Theory

A Design Pattern Every Python Developer Should Know

The problem template method solves

So why is it important for Python devs?

Conclusion

Django + PgBouncer in Production: Pitfalls, Fixes, and Survival Tricks

Why did we need to add PgBouncer?

Installation and configuration process

The difficult choice of the pool mode

The tricks we used to solve transaction mode issues and make our Django application reliable

Migrations

Search path

Disabling server side cursor

Reliability: Fallback from PgBouncer to Postgres

Conclusion