DEV Community: Saleh Azimidokht

The API Worked. The Architecture Didn’t.

Saleh Azimidokht — Sat, 19 Sep 2026 15:04:32 +0000

The API worked.

Requests returned 200 OK.

The database had the right data.

Tests were passing.

The frontend was happy.

And yet, the system was becoming harder to operate every week.

This is one of the easiest traps in backend development:

A working API does not necessarily mean a working architecture.

An endpoint can be perfectly implemented while the system around it is slowly becoming fragile.

The Endpoint Looks Fine

Imagine a simple endpoint:

POST /orders/

It creates an order and returns:

{
  "id": 123,
  "status": "created"
}

The implementation might look completely reasonable:

def create_order(data):
    order = Order.objects.create(**data)

    send_confirmation_email(order)
    update_inventory(order)
    notify_warehouse(order)

    return order

Nothing looks obviously wrong.

The API works.

The tests pass.

The response is correct.

But now imagine that:

sending the email takes 800ms
inventory is handled by another service
warehouse notification sometimes takes 2 seconds
one of those services occasionally times out

Suddenly, creating an order is no longer just creating an order.

The problem is not the endpoint.

The problem is the architecture behind it.

Correctness Is Not the Same as Architecture

There are several different questions we should ask about a backend system.

Does the API work?

Does it return the expected response?

Is the business logic correct?

Does it enforce the right rules?

Is the system reliable?

What happens when dependencies fail?

Is it scalable?

What happens when traffic increases?

Is it maintainable?

Can another engineer safely change it six months from now?

These are different properties.

A system can be correct and still be difficult to scale.

It can be fast and still be unreliable.

It can pass every test and still have a bad architecture.

One Request Can Do Too Much

A common pattern is gradually adding responsibilities to an endpoint.

It starts simple:

Request
   ↓
Validate
   ↓
Save
   ↓
Response

Then requirements arrive.

"Also send an SMS."

"Also update analytics."

"Also notify the admin."

"Also generate the invoice."

"Also sync with the external service."

Eventually:

                    ┌── Email
                    ├── SMS
                    ├── Analytics
Request → API → DB ─┼── Invoice
                    ├── External API
                    └── Notifications

Every individual operation might be valid.

The architecture is the problem.

The request lifecycle has become coupled to everything that happens after the database write.

Failure Makes It More Complicated

Suppose the database transaction succeeds.

Then the external API fails.

Create Order
     ↓
Database ✓
     ↓
Send Notification
     ↓
External API ✗

Should the order be rolled back?

Usually not.

But now the API needs to deal with partial failure.

Maybe we retry.

What if the retry succeeds but the API request times out?

The client might retry the entire request.

Now we could create the order twice.

So we need idempotency.

Then an idempotency key.

Then somewhere to store that key.

A seemingly simple endpoint has turned into a distributed systems problem.

Not because someone wrote terrible code.

Because multiple responsibilities were connected to one request.

The Synchronous Everything Problem

One of the easiest architectural mistakes is doing everything synchronously.

def create_order(data):
    order = create_order(data)

    send_email(order)
    send_sms(order)
    sync_with_partner(order)
    generate_report(order)

    return order

The API response now depends on all of these operations.

If the slowest operation takes three seconds:

API latency ≈ database + email + SMS + partner API + report

Even if creating the order itself takes only 20ms.

A better architecture might be:

Request
   ↓
Create Order
   ↓
Commit
   ↓
Response
   │
   └── Background Work
          ├── Email
          ├── SMS
          ├── Partner Sync
          └── Report

The important part is not simply "use a queue."

The important part is:

Separate operations that must happen before the response from operations that can happen after it.

Sometimes that means a background worker.

Sometimes an event.

Sometimes an outbox.

Sometimes simply moving non-critical work outside the request path.

The architecture should follow the actual business requirements.

The Database Can Hide Problems Too

Consider a perfectly valid ORM query:

orders = Order.objects.all()

for order in orders:
    print(order.customer.name)

It works.

For 20 orders, it might be fine.

For 20,000 orders, you may have an N+1 query problem.

The API contract didn't change.

The endpoint still works.

But the system doesn't behave well under realistic load.

The same thing happens with:

missing indexes
unbounded queries
large payloads
expensive serialization
unnecessary joins
repeated external calls

A working endpoint is not proof that the data access pattern is healthy.

"We'll Add Caching Later"

Caching is another common architectural band-aid.

A query becomes slow.

Instead of asking why, we add Redis.

Sometimes that's exactly the right solution.

But sometimes the real problem is:

Missing index

or:

N+1 queries

or:

Fetching data we don't need

or:

Doing an expensive aggregation on every request

Adding a cache can make the endpoint faster while hiding the actual bottleneck.

Now we have:

API
 ↓
Redis
 ↓
Database

plus:

cache invalidation
TTL decisions
stale data
cache misses
cache failures

The system is faster.

But also more complicated.

Performance improvements should start with measurement and understanding the bottleneck.

Microservices Don't Automatically Fix Architecture

Sometimes the response to a growing monolith is:

"Let's split it into microservices."

But moving bad boundaries into separate services doesn't create good architecture.

Imagine:

Order Service
     ↓
Payment Service
     ↓
Inventory Service
     ↓
Notification Service

If every request needs all four services synchronously, you've created a distributed monolith.

Instead of:

Function call

you now have:

Network call

And network calls introduce:

latency
timeouts
retries
partial failures
service discovery
observability requirements
deployment coordination

Microservices can solve real organizational and scaling problems.

But service boundaries should exist because there is a meaningful boundary in the system.

Not simply because the application has become large.

Architecture Is About Boundaries

One of the most useful questions in backend development is:

What should be allowed to depend on what?

For example:

HTTP Layer
    ↓
Application Logic
    ↓
Domain Logic
    ↓
Persistence

The exact architecture doesn't have to look like this.

The important idea is boundaries.

Your HTTP handler shouldn't need to know how an email provider works.

Your domain logic shouldn't need to know about HTTP status codes.

Your database model shouldn't become the entire business layer.

Your notification system shouldn't determine whether an order is valid.

Good boundaries make change cheaper.

Ask What Happens When Things Fail

A happy-path architecture is easy to design.

The real architecture appears when something fails.

Ask questions like:

What if the database is slow?

Does the entire application become slow?

What if Redis is unavailable?

Can the application continue?

What if an external API times out?

Do we retry? How many times?

What if the client retries the request?

Can we safely process it twice?

What if a worker crashes halfway through a job?

Can the job be retried safely?

What if the same event is processed twice?

Is the operation idempotent?

These questions often reveal more about an architecture than another diagram of the happy path.

The API Is Only the Surface

When we review an API, we often focus on:

REST conventions
response structure
status codes
validation
serializers

Those things matter.

But they don't tell the whole story.

A backend system has many layers:

                    API Contract
                         │
                         ↓
                  Application Logic
                         │
                         ↓
                    Data Access
                         │
                         ↓
                Infrastructure
                         │
                         ↓
                External Systems

The API is the surface.

The architecture is everything underneath it.

A Better Definition of "It Works"

Instead of asking only:

Does the API work?

Ask:

Does the system behave correctly when the happy path disappears?

A production backend should have reasonable answers for:

dependency failures
retries
timeouts
duplicate requests
concurrent operations
large datasets
increasing traffic
partial failures
background job failures
database contention

Not every application needs an elaborate solution for all of these.

That's important.

Architecture is not about preparing a small application for billions of users.

It's about preparing the system for the problems it is actually expected to face.

Keep the Architecture Boring

Good backend architecture is often surprisingly boring.

You might end up with:

API
 ↓
PostgreSQL

And that's fine.

Maybe you later need:

API
 ↓
PostgreSQL
 ↓
Background Worker

That's fine too.

Then perhaps traffic grows:

                ┌── API
Load Balancer ──┼── API
                └── API
                     │
                     ↓
                 PostgreSQL
                     │
                     ↓
                  Workers

Architecture should evolve because requirements evolve.

Not because technology is available.

You don't get architectural maturity by adding more boxes to a diagram.

You get it by understanding why each box exists.

The Real Test

A good architecture should make the next change easier.

If adding a new notification provider requires changing the order creation flow, you have coupling.

If changing the database requires rewriting business logic, you have coupling.

If one external service being unavailable prevents unrelated functionality from working, you have coupling.

If scaling one feature requires scaling the entire application, you may have a boundary problem.

The goal isn't to eliminate coupling.

That's impossible.

The goal is to make coupling intentional and understandable.

Final Thought

The API can work perfectly.

The tests can be green.

The deployment can be successful.

And the architecture can still be wrong for the system you're building.

That's why backend engineering is more than writing endpoints.

It's about understanding:

dependencies
boundaries
failure modes
data ownership
consistency
concurrency
scaling
operational cost

The API is what the client sees.

The architecture is what determines whether the system remains healthy as the system grows.

A working API is a feature.

A sustainable architecture is a system.

Read the full version

This article is part of my backend engineering notes.

I publish the full version, along with other practical backend architecture articles, on my personal site:

CyberHuginn

If you're interested in backend engineering, system design, APIs, databases, and the trade-offs behind real-world systems, you may find the other notes useful too.

That doesn’t mean you should use Redis for everything!

Saleh Azimidokht — Sat, 19 Sep 2026 12:00:14 +0000

Redis is fast.

That doesn’t mean you should use Redis for everything.

It’s easy to reach for Redis whenever you need caching, OTPs, rate limiting, locks, queues, sessions, or temporary data.

But every new infrastructure component comes with a cost.

More services to operate.
More failure modes.
More things to monitor.
More distributed-state problems to reason about.

Sometimes Redis is exactly the right tool.

Sometimes PostgreSQL is enough.

And sometimes the simplest solution is not adding another component at all.

I wrote about how I think about these trade-offs, and when Redis can add more complexity than value.

Read the full article:

https://cyberhuginn.com/notes/when-redis-is-not-the-solution

The Hidden Cost of Django REST Framework Serializers

Saleh Azimidokht — Mon, 07 Sep 2026 08:21:04 +0000

Your Django REST Framework API can have fast database queries and still be slow.

That's one of the most confusing performance problems in Django applications.

You check PostgreSQL.

The queries look fast.

You optimize your views.

Everything seems fine.

But the endpoint is still taking hundreds of milliseconds—or even seconds.

One place developers often forget to investigate is the Django REST Framework serializer.

A serializer is not always just converting Python objects into JSON.

It can trigger database queries, access relationships, execute Python code, calculate fields, and recursively serialize nested objects.

And that's where things can get expensive.

The N+1 Query Problem Hiding Inside a Serializer

Consider a simple serializer:

class VehicleSerializer(serializers.ModelSerializer):
    customer_name = serializers.SerializerMethodField()

    class Meta:
        model = Vehicle
        fields = (
            "id",
            "plate_number",
            "customer_name",
        )

    def get_customer_name(self, obj):
        return obj.customer.name

Looks perfectly reasonable.

But where does obj.customer come from?

If the customer relationship hasn't been loaded, Django may execute another SQL query.

With 100 vehicles, you could end up with:

1 query   → fetch vehicles
100 queries → fetch customers

Total: 101 queries

That's the classic N+1 query problem.

And the dangerous part is that the serializer itself doesn't look like a database operation.

SerializerMethodField Is Not Free

SerializerMethodField is one of my favorite DRF features.

It's also one of the easiest ways to accidentally create expensive APIs.

Consider:

class ServiceSerializer(serializers.ModelSerializer):
    last_service = serializers.SerializerMethodField()

    def get_last_service(self, obj):
        return (
            Service.objects
            .filter(ownership=obj.ownership)
            .order_by("-created_at")
            .first()
        )

This performs a database query every time get_last_service() is called.

Serialize 500 services?

Potentially:

1 main query
+
500 additional queries
=
501 queries

The code is readable.

The API is correct.

And yet the performance can be terrible.

This is why correct code isn't necessarily efficient code.

The Fix Usually Isn't Inside the Serializer

One of the most important lessons I've learned when optimizing Django APIs is this:

The serializer should not be responsible for discovering data that the database could have prepared.

Instead of querying for every object, move the work into the QuerySet.

For example, you can use Subquery:

from django.db.models import OuterRef, Subquery

last_service = Service.objects.filter(
    ownership=OuterRef("ownership"),
).order_by("-created_at")

queryset = Vehicle.objects.annotate(
    last_service_id=Subquery(
        last_service.values("id")[:1]
    )
)

Now the database prepares the information as part of the main query.

Your serializer becomes simpler:

class VehicleSerializer(serializers.ModelSerializer):
    last_service_id = serializers.IntegerField(read_only=True)

    class Meta:
        model = Vehicle
        fields = (
            "id",
            "plate_number",
            "last_service_id",
        )

The architecture becomes:

Database
    ↓
Optimized QuerySet
    ↓
Annotations
    ↓
Serializer
    ↓
JSON

Instead of:

Database
    ↓
Serializer
    ↓
"Let's query something"
    ↓
Another query
    ↓
Another query
    ↓
Another query

select_related() vs prefetch_related()

When working with Django REST Framework serializers, you should always pay attention to the relationships being accessed.

For single-valued relationships:

ForeignKey
OneToOneField

use:

select_related()

For example:

vehicles = Vehicle.objects.select_related("customer")

Now Django can retrieve the vehicle and customer using a SQL JOIN.

For collections such as:

ManyToManyField
Reverse ForeignKey

use:

prefetch_related()

For example:

services = (
    Service.objects
    .prefetch_related("products")
)

A simple rule to remember:

ForeignKey / OneToOne
        ↓
select_related()

ManyToMany / Reverse FK
        ↓
prefetch_related()

These two methods are some of the most important tools for preventing N+1 queries in Django APIs. (DEV Community)

Nested Serializers Make Things Worse

Nested serializers are convenient.

But convenience can hide expensive database access.

Imagine:

class ProductSerializer(serializers.ModelSerializer):
    class Meta:
        model = Product
        fields = ("id", "name")


class ServiceSerializer(serializers.ModelSerializer):
    products = ProductSerializer(many=True)

    class Meta:
        model = Service
        fields = (
            "id",
            "products",
        )

Now imagine your API returns 1,000 services.

Every service needs its products.

Without prefetching, your API can start generating queries like:

Service query
Product query
Product query
Product query
...

And nested relationships can go even deeper:

Service
 ├── Customer
 │    └── Address
 └── Products
      └── Category

A response that looks innocent in JSON can represent a surprisingly expensive data-access pattern.

Don't Build One Giant Serializer

Another common mistake is trying to use one serializer for everything.

For example:

VehicleSerializer

gets used for:

List endpoints
Detail endpoints
Create endpoints
Update endpoints
Admin endpoints
Search endpoints

Eventually, the serializer becomes huge.

A list endpoint might only need:

class VehicleListSerializer(serializers.ModelSerializer):
    class Meta:
        model = Vehicle
        fields = (
            "id",
            "plate_number",
            "color",
        )

While a detail endpoint can provide more information:

class VehicleDetailSerializer(serializers.ModelSerializer):
    customer = CustomerSerializer()

    class Meta:
        model = Vehicle
        fields = (
            "id",
            "plate_number",
            "color",
            "customer",
        )

This isn't unnecessary duplication.

It's API design.

A list endpoint shouldn't return an entire object graph just because the detail endpoint needs it.

Smaller Responses Are Usually Better

More data isn't always better.

Consider an API response containing:

Customer
 ├── Vehicles
 ├── Services
 ├── Invoices
 ├── Payments
 ├── Addresses
 └── Orders

It might look impressive.

But every additional relationship can increase:

Database work
Serialization time
Response size
Memory usage
Network transfer
Frontend processing

The API should return the data the client needs—not everything the database knows.

Measure Before Optimizing

This is probably the most important rule.

Don't look at a serializer and say:

"This probably causes performance problems."

Measure it.

For Django APIs, useful things to measure include:

SQL query count
SQL query duration
Serializer execution time
Total request duration
Response size
CPU usage

Tools such as Django Debug Toolbar, Django Silk, and APM platforms can help you find where the time is actually going.

Because sometimes the database isn't the bottleneck.

Imagine:

Database:       40 ms
View logic:     30 ms
Serialization: 650 ms
JSON rendering: 80 ms

Total:          800 ms

Optimizing a 40 ms database query isn't going to solve your 800 ms API response.

Profile the entire request.

A Simple DRF Performance Checklist

When a Django REST Framework endpoint becomes slow, I usually start here:

1. Count the queries

How many SQL queries does the endpoint execute?

2. Inspect SerializerMethodField

Look for database access inside:

get_<field_name>()

3. Inspect relationship access

Look for:

obj.customer
obj.owner
obj.category
obj.products.all()

4. Check select_related()

Are your ForeignKey and OneToOneField relationships loaded efficiently?

5. Check prefetch_related()

Are your ManyToMany and reverse relationships prefetched?

6. Look at annotations

Can a calculation be performed by the database instead of repeatedly inside Python?

7. Reduce nested data

Does the frontend actually need all those nested objects?

8. Separate serializers

Does the list endpoint really need the same serializer as the detail endpoint?

9. Measure again

Never assume the optimization worked.

Measure before and after.

The Real Cost of a Serializer

Django REST Framework serializers aren't inherently slow.

The problem is what we ask them to do.

A serializer becomes expensive when it:

Executes database queries repeatedly
Accesses unloaded relationships
Performs expensive Python calculations
Uses deeply nested serializers
Returns unnecessary data
Hides database access inside SerializerMethodField

The best optimization is often not changing the serializer.

It's changing the QuerySet behind it.

Think about your API like this:

Request
   ↓
View
   ↓
Optimized QuerySet
   ↓
Database
   ↓
Serializer
   ↓
Minimal JSON Response

Not:

Request
   ↓
View
   ↓
Huge QuerySet
   ↓
Serializer
   ↓
Query
   ↓
Query
   ↓
Query
   ↓
N+1
   ↓
Slow API

Final Thought

The next time you see a slow Django REST Framework endpoint, don't only inspect the SQL.

Inspect what happens after the QuerySet is evaluated.

Your database query might be fast.

Your serializer might be the expensive part.

And that hidden cost becomes much more visible as your dataset grows.

I wrote a deeper technical breakdown with more examples, optimization strategies, select_related(), prefetch_related(), annotations, nested serializers, and practical debugging techniques:

👉 The Hidden Cost of Django REST Framework Serializers

If you're building production Django APIs, understanding the relationship between QuerySets, serializers, and database queries can make a huge difference.

django #python #djangorestframework #drf #backend #api #webdevelopment #performance #database #programming

I Built a Signed Webhook Receiver for Cross-Server Communication

Saleh Azimidokht — Tue, 11 Aug 2026 12:05:48 +0000

Sometimes your application can reach an external service from one server, but not from another.

I ran into this problem while working on one of my projects. I needed my server in Iran to communicate with Telegram, but the connection wasn't reliable from inside Iran.

Instead of moving the whole application, I built a small intermediate service:

Signed Webhook Receiver

It is a lightweight FastAPI service that receives requests signed with an RSA private key and verifies them using the corresponding public key before processing them.

Your Server
     |
     | RSA Signed Request
     v
Webhook Receiver
     |
     | HTTP Request
     v
External Service

The receiver can be useful for:

Secure server-to-server communication
Webhooks and internal APIs
Acting as a controlled proxy/gateway
Connecting servers across different network environments
Payment integrations where a provider requires requests from an Iranian IP

For example, if your main application is hosted outside Iran but a payment gateway only accepts requests from Iranian IP addresses, an Iranian server can act as the intermediate gateway:

Foreign Server
      |
      | Signed Request
      v
Iranian Gateway Server
      |
      v
Payment Gateway

The important part is that this isn't an open proxy. Requests can be authenticated and the gateway can be restricted to specific operations and destinations.

The project is built with Python, FastAPI, Cryptography, Docker, and Traefik and is open source.

View the project on GitHub

I also wrote more technical notes and development articles on my website:

Building a Secure Webhook Receiver for Server-to-Server Communication | CyberHuginn

Designing a Gold Jewelry E-Commerce Database with Django

Saleh Azimidokht — Tue, 04 Aug 2026 05:04:51 +0000

When I accepted a project to build an online gold jewelry store, I thought it would be just another e-commerce platform.

Products. Orders. Payments.

Nothing unusual.

I couldn't have been more wrong.

A few hours into the database design, I realized the real challenge wasn't Django—it was understanding the business.

Unlike a regular online store, customers aren't buying a generic product. They're buying a very specific variation of that product.

A single ring, for example, can exist in multiple versions:

Different weights
Different karats
Different sizes
Different gemstones
Different making fees
Different prices
Different inventory

That simple observation completely changes how your database should be designed.

The Common Mistake

Many developers model their orders like this:

Order
 └── Product

That works perfectly for books, digital products, or simple inventory.

It completely falls apart for jewelry.

Because the customer isn't purchasing the Product.

They're purchasing one specific variation of that product.

The Missing Model

Instead of attaching orders directly to Product, I introduced another layer:

Product
    └── ProductVariable
            ├── Price
            ├── Stock
            ├── Making Fee
            ├── Weight
            ├── Karat
            └── Attributes

Now every purchasable item has its own inventory, pricing, and specifications while still belonging to the same parent product.

This approach also makes searching and filtering much easier because attributes become reusable across multiple products.

Start From Business Scenarios

Before writing models, I always walk through real business scenarios.

Questions like:

What exactly is the customer buying?
Can inventory differ between variations?
Can price change based on weight?
What happens when an item is out of stock?
Can customers order custom-made jewelry?

Those questions usually define your entities long before you write your first Django model.

This article only scratches the surface.

In the full version, I explain:

How to identify entities using Use Cases
Building an ER Diagram
Designing Django models
Modeling ProductVariable
Categories vs Tags
Product Attributes
Inventory management
Ordering and payment architecture
Real-world jewelry business scenarios

👉 Read the complete article here:

https://cyberhuginn.com/notes/designing-a-gold-jewelry-ecommerce-database-with-django

If you're building an e-commerce platform with Django, especially one that sells configurable products, this design pattern can save you from painful database refactoring later.

Why Every Small SaaS Needs Uptime Monitoring

Saleh Azimidokht — Sat, 01 Aug 2026 17:34:22 +0000

Building software has never been easier.

Keeping it online is the hard part.

Whether you're running a personal project, an internal API, a startup MVP, or a growing SaaS business, downtime can quickly become expensive. Users lose trust, support requests increase, and revenue disappears while you're unaware that something has gone wrong.

The worst part?

Most outages aren't discovered by monitoring systems.

They're discovered by users.

That realization is exactly what led me to build Bidar—a lightweight uptime monitoring platform focused on one simple goal:

Notify developers as soon as their services become unavailable.

The Hidden Cost of Downtime

It's easy to think of downtime as "just a server issue."

In reality, the impact is much broader.

Even a short outage can affect:

User trust
Customer satisfaction
Conversion rates
Search rankings
Team productivity
Brand reputation

Your users don't care whether the issue was caused by a failed deployment, DNS problem, database outage, or cloud provider incident.

They only know one thing:

Your service wasn't available when they needed it.

Why Manual Monitoring Doesn't Scale

In the beginning, many developers rely on manual checks.

They refresh the website.

They test an API endpoint.

They occasionally check server metrics.

That works for hobby projects.

It stops working when real users depend on your application.

You can't monitor your services 24 hours a day.

You can't wake up every hour to verify your API is still responding.

Automation eventually becomes a necessity.

What Should You Monitor?

A good monitoring solution should cover more than just your homepage.

Some of the most valuable things to monitor include:

Website availability
REST API endpoints
SSL certificate expiration
Response time
HTTP status codes
Critical customer-facing pages
Internal services

Monitoring the right endpoints allows you to detect problems before your customers notice them.

What Makes a Good Monitoring Tool?

After working on several backend systems, I've found that a monitoring solution doesn't need hundreds of features.

It needs to do a few things really well.

Fast Detection

The sooner you're notified, the sooner you can fix the issue.

Reliable Alerts

Notifications should arrive immediately through the channels you actually use.

Easy Setup

Monitoring should take minutes—not hours.

Clear Results

The goal isn't generating pretty dashboards.

The goal is answering one question:

Is my service healthy?

Why I Built Bidar

While working on Django projects and APIs, I wanted a monitoring service that focused on uptime instead of trying to be a complete observability platform.

Many existing tools are incredibly powerful.

They also come with dozens of dashboards, metrics, traces, and features that smaller teams often don't need.

So I built Bidar.

Its philosophy is simple:

Add your website or API.
Configure monitoring.
Get notified when something goes wrong.

That's it.

No unnecessary complexity.

Just reliable uptime monitoring.

Who Is It For?

Bidar is especially useful for:

Indie Hackers
SaaS founders
Freelancers managing client websites
Small development teams
Backend developers
Anyone running production APIs

If uptime matters to your users, monitoring should matter to you.

Final Thoughts

Reliable software isn't just about writing good code.

It's also about knowing when things stop working.

Monitoring helps you detect issues faster, reduce downtime, and respond before your users start sending emails asking if your service is down.

If you're looking for a lightweight uptime monitoring platform, I'd love for you to check out Bidar.

🌐 Website: https://bidarhq.ir

I'm always looking for feedback from developers.

If there's a feature you'd like to see, let me know!

About the Author

I'm a backend developer focused on Django, distributed systems, developer tools, and open-source software.

Website: https://cyberhuginn.com

GitHub: https://github.com/cyberhuginn

I Built a Lightweight Health Check Package for Django

Saleh Azimidokht — Sat, 01 Aug 2026 17:30:06 +0000

While working on several Django projects, I often needed a simple endpoint to verify that the application was actually healthy—not just running.

Most existing solutions were either too heavy, required extra configuration, or didn’t provide the flexibility I wanted.

So I built django-healthkit.

What it does

The package lets you expose a health endpoint that can verify different parts of your application.

Current checks include:

Database connectivity
Cache availability
Disk usage
Memory usage
CPU usage

Configuration is intentionally simple:

HEALTH_CHECKS = [
    "database",
    "cache",
    "disk",
    "memory",
    "cpu",
]

Then expose the endpoint and you're ready to use it with:

Docker health checks
Kubernetes probes
Traefik
Nginx
Monitoring systems
Uptime monitoring services

Why I built it

My goal wasn't to create another monitoring platform.

I wanted a small package that answers one simple question:

Is my Django application actually healthy?

No dashboards.

No unnecessary dependencies.

Just a clean JSON response that can be consumed by automation.

What's next?

This is only the first release.

Some ideas planned for future versions:

Custom health checks
Async support
Response customization
More built-in system checks
Better integrations with monitoring tools

I'd love your feedback

If you're using Django, I'd really appreciate your thoughts.

What health checks are missing?
What features would make this useful in production?
Any ideas for improving the API?

About the author

I'm a backend developer focused on Django, distributed systems, developer tools, and open-source software.

Website: https://cyberhuginn.com

GitHub: https://github.com/cyberhuginn

DEV Community: Saleh Azimidokht

The API Worked. The Architecture Didn’t.

The Endpoint Looks Fine

Correctness Is Not the Same as Architecture

One Request Can Do Too Much

Failure Makes It More Complicated

The Synchronous Everything Problem

The Database Can Hide Problems Too

"We'll Add Caching Later"

Microservices Don't Automatically Fix Architecture

Architecture Is About Boundaries

Ask What Happens When Things Fail

The API Is Only the Surface

A Better Definition of "It Works"

Keep the Architecture Boring

The Real Test

Final Thought

Read the full version

That doesn’t mean you should use Redis for everything!

The Hidden Cost of Django REST Framework Serializers

The N+1 Query Problem Hiding Inside a Serializer

SerializerMethodField Is Not Free

The Fix Usually Isn't Inside the Serializer

select_related() vs prefetch_related()

Nested Serializers Make Things Worse

Don't Build One Giant Serializer

Smaller Responses Are Usually Better

Measure Before Optimizing

A Simple DRF Performance Checklist

1. Count the queries

2. Inspect SerializerMethodField

3. Inspect relationship access

4. Check select_related()

5. Check prefetch_related()

6. Look at annotations

7. Reduce nested data

8. Separate serializers

9. Measure again

The Real Cost of a Serializer

Final Thought

django #python #djangorestframework #drf #backend #api #webdevelopment #performance #database #programming

I Built a Signed Webhook Receiver for Cross-Server Communication

Designing a Gold Jewelry E-Commerce Database with Django

The Common Mistake

The Missing Model

Start From Business Scenarios

Why Every Small SaaS Needs Uptime Monitoring

The Hidden Cost of Downtime

Why Manual Monitoring Doesn't Scale

What Should You Monitor?

What Makes a Good Monitoring Tool?

Fast Detection

Reliable Alerts

Easy Setup

Clear Results

Why I Built Bidar

Who Is It For?

Final Thoughts

About the Author

I Built a Lightweight Health Check Package for Django

What it does

Why I built it

What's next?

I'd love your feedback

Links

About the author