DEV Community: Ezeana Micheal

The Bilingual Developer: Python and Go Primitive Data Types

Ezeana Micheal — Fri, 29 May 2026 15:50:56 +0000

As discussed in the previous article on the variables about the need of programming languages to store information. This article will be about how the different data is stored. Let’s slow it down a bit and really think about it. If storage is where data lives… then data types are basically how that data is shaped inside memory. And depending on the language you’re using, that “shape” changes a lot. Primitive data types are the most basic building blocks used to represent values inside a program.

When learning both Python and Go, understanding their primitive data types is one of the fastest ways to understand the design philosophy behind each language.

Understanding Primitive Data Types

Primitive data types are the simplest forms of data a programming language can handle directly. They represent single values such as:

Text
Numbers
Boolean values (true or false)
Fixed constant values

Text and Characters

Strings in Python

In Python, text is represented using the str data type. A string, simply put, is a sequence of characters enclosed in quotation marks.

name = "Michael"  
message = 'Hello World'

Python treats strings as Unicode by default, meaning they can store characters from different languages and symbols.

emoji = "😊"  
language = "Python"

One of Python’s strengths is how simple string manipulation feels.

first_word = "Go"  
last_word = "Python"

full_word = first_word + " " + last_word

print(full_word)

Output:

Go Python

Python does not have a separate character (char) data type. A single character is simply considered a string of length one.

letter = "A"
print(type(letter))

Output:

<class 'str'>

This design keeps the language simpler because developers only need to think about one text type instead of multiple character-based types.

Strings and Runes in Go

Go also uses strings for textual data.

package main

import "fmt"

func main() {  
    name := "Michael"  
    fmt.Println(name)  
}

But Go handles characters differently from Python.

In Go:

A string represents a sequence of bytes.
A rune represents a single Unicode character.

A rune is actually an alias for int32.

var letter rune = 'A'

Notice something important:

Strings use double quotes " "
Runes use single quotes ' '

This distinction is very important in Go.

package main
import "fmt"

func main() {  
    var character rune = 'G'

    fmt.Println(character)  
}

Output:

The output is numeric because Go stores runes internally using Unicode code points.

To print the actual character:

fmt.Printf("%cn", character)

Output:

Go’s approach gives developers more control over memory and encoding behavior, especially for systems programming and high-performance applications.

Numbers

Numbers are another core primitive data type.

Both Python and Go support:

Integers
Floating-point numbers

Integers and Floats in Python

Python makes numeric programming simple.

age = 25  
price = 19.99

Python automatically determines the type.

print(type(age))  
print(type(price))

Output:

<class 'int'>  
<class 'float'>

One important feature of Python is that integers can grow very large automatically.

big_number = 999999999999999999999999999999

Python dynamically allocates memory for large integers behind the scenes.

This flexibility is convenient because developers rarely worry about integer overflow or memory size during basic programming.

Integers and Floats in Go

Go is stricter and more explicit.

var age int = 25

var price float64 = 19.99

Go supports multiple integer sizes:

int8
int16
int32
int64

And floating-point types:

float32
float64

Example:

var smallNumber int8 = 100  
var largeNumber int64 = 9000000000

This explicit sizing is important because each type uses a specific amount of memory.

Type	Size
int8	8 bits
int16	16 bits
int32	32 bits
int64	64 bits

Go forces developers to think more carefully about memory usage and performance.

For example:

var x int32 = 10  
var y int64 = 20

// This causes an error  
// fmt.Println(x + y)

Go does not automatically mix different integer sizes. Developers must explicitly convert types.

fmt.Println(int64(x) + y)

This strictness reduces accidental bugs and improves predictability in large systems.

Booleans

Booleans represent logical truth values.

They are heavily used in:

Conditions
Comparisons
Decision-making statements

Booleans in Python

Python uses:

True and False

Notice the capitalization.

is_logged_in = True  
is_admin = False

Example:

age = 20  
if age >= 18:  
    print(True)

Output:

True

Python’s boolean system is highly flexible because many values can behave as truthy or falsy.

Examples of falsy values:

0

None

""

[]

False

Everything else is generally considered truthy.

Booleans in Go

Go also supports boolean values, but with stricter rules(as usual).

var isLoggedIn bool = true  
var isAdmin bool = false

Notice the lowercase keywords:

true and false

Go does not allow non-boolean values in conditional statements.

This is invalid:

var number int = 1

if number {  
    fmt.Println("Hello")  
}

Python allows similar truthy checks, but Go requires an actual boolean expression.

Correct Go example:

if number == 1 {  
    fmt.Println("Hello")  
}

This design improves clarity and reduces ambiguity.

Constants

Constants are values that should never change during program execution.

Constants in Python

Python does not have a true constant keyword. Instead, developers follow a naming convention using uppercase variable names.

PI = 3.14159  
MAX_USERS = 100

However, Python does not enforce immutability.

PI = 10

This still works. The uppercase naming style simply communicates intent to other developers. Python relies heavily on developer discipline and readability conventions.

Constants in Go

Go provides an actual const keyword.

const Pi = 3.14159  
const MaxUsers = 100

Once declared, constants cannot be modified.

const Age = 20

// Error  
// Age = 30

This enforcement makes programs safer and more predictable. Go constants can also exist without explicitly specifying a type.

const Name = "GoLang"

The compiler determines the appropriate type automatically.

Conclusion

In Python, primitive types are designed to feel natural and easy to use. Developers can move quickly without worrying much about memory sizes or strict typing rules.

In Go, primitive types are more structured and explicit. Developers are expected to think carefully about memory, type safety, and predictability.

Comment , Share and Like, thanks for reading.

The N+1 Query That Killed Our Database, And How I Fixed It

Ezeana Micheal — Mon, 25 May 2026 17:39:38 +0000

Everything Worked…But Not Well

APIs are affected by the way data is retrieved from the database, and that's something that affected a recent teammate and me during development. In our regular development process, during review and maintenance, the APIs worked, responses came back well, no visible errors. But during this process, we noticed that things started to slow down. Endpoints that used to respond fast suddenly began taking longer, CPU usage on the database increased, and retrieval speed became terrible under load.

At first, we thought:

Maybe the server wasn't powerful enough
Maybe network latency was the issue
Maybe too many requests were hitting the API

But the real issue was hiding inside our database queries.

What Actually Is The N+1 Query Problem?

The N+1 query problem is one of the most common performance issues in backend development, especially when working with relational databases and ORMs(as I, a fan of Django, do). I’m gonna explain this more in SQL terms using retrieval speed and database load.

The problem happens when your application performs:

1 query to retrieve parent records
Then N extra queries to retrieve related child records

So instead of making one optimized query, the application keeps asking the database more questions repeatedly. This increases the query count, read time, database load, and the API response time. 1 issue, several systems affected.

A Simple Example

Let's say we have 2 tables:

Users
Orders

We first retrieve all users.

SELECT * FROM users;

Now imagine there are 100 users. Then, for every user retrieved, another query runs to fetch their orders.

SELECT * FROM orders WHERE user_id = 1;  
SELECT * FROM orders WHERE user_id = 2;  
SELECT * FROM orders WHERE user_id = 3;

And it keeps going. So instead of 1 query, you now have 101 queries. That extra load destroys retrieval speed.

Why This Problem Is Dangerous

The dangerous part is that during development, you might not even notice it. If your database only has just about 5 users and 10 orders, Everything still feels fast.

But once production data grows:

Hundreds of users
Thousands of records
More API requests

The database starts struggling badly. This is why some APIs feel fast during testing but start to slow down after deployment.

The Mistake We Made

The issue wasnt obvious at first because the code itself looked completely normal. We had an endpoint that needed to return users alongside their related orders.

Something like:

User information
Their recent orders
Order counts
Related details

The endpoint worked perfectly during development. But internally, Django was fetching related records separately for every user being serialized. Which meant the API kept hitting the database repeatedly behind the scenes.

The code looked clean.

users = User.objects.all()

serializer = UserSerializer(users, many=True)

But in the serializer, related order data was being accessed for every single user.

class UserSerializer(serializers.ModelSerializer):

    orders = OrderSerializer(many=True)

    class Meta:

        model = User

        fields = ['id', 'name', 'orders']

This is where the real problem started. When Django tried to serialize the response, it kept querying orders separately per user. So if there were 500 users, the system would do:

1 query to retrieve users
Hundreds of additional queries to retrieve orders

That is the N+1 query problem. The scary part is that nothing looked wrong from the surface. The endpoint returned the correct data and no errors, just slow performance. And as traffic increased, the database load became worse. It was slow because the application kept repeatedly asking for related data instead of retrieving it efficiently.

The fix was adding query optimization directly to the queryset.

users = User.objects.prefetch_related('orders')

serializer = UserSerializer(users, many=True)

That single optimization drastically reduced the number of database hits. Instead of querying orders repeatedly for every user, Django retrieved them efficiently in bulk. Same endpoint and response, much better performance.

Understanding `select_related()`

One major fix for this problem in Django is:

select_related()

select_related() is used for relationships like:

ForeignKey
OneToOneField

What it basically does is perform a SQL JOIN and retrieve related data in a single query. Instead of this:

users = User.objects.all()

for user in users:  
    print(user.profile.phone)

Which may generate multiple queries…

You do this:

users = User.objects.select_related('profile')  
for user in users:  
    print(user.profile.phone)

Now Django joins the tables together and retrieves everything at once.

So instead of:

1 query for users
Multiple queries for profiles

You now get:

1 optimized query

Much faster and cleaner.

Understanding `prefetch_related()`

Another optimization is:

prefetch_related()

This is used mostly for:

ManyToMany relationships
Reverse ForeignKey relationships

Unlike select_related(), this does not use SQL JOINs directly. Instead, Django performs separate queries but combines the results efficiently in memory.

For example:

users = User.objects.prefetch_related('orders')

Django may run:

SELECT * FROM users;  
SELECT * FROM orders WHERE user_id IN (1,2,3,4...);

Instead of:

SELECT * FROM orders WHERE user_id = 1;  
SELECT * FROM orders WHERE user_id = 2;  
SELECT * FROM orders WHERE user_id = 3;

Which is far more efficient. So rather than hundreds of queries, you may only have two.

The Difference Between `select_related()` And `prefetch_related()`

`select_related()`

Uses SQL JOINs
Best for ForeignKey and OneToOne relationships
Retrieves related data in a single query

`prefetch_related()`

Uses multiple optimized queries
Combines data in Python memory
Best for ManyToMany and reverse relationships

Both solve the same problem differently.

The Result

After fixing the queries:

Response times dropped massively
Database load reduced
API became stable again
Retrieval speed improved significantly

The funny thing is that we didnt upgrade the server. We didnt increase RAM. We didnt change infrastructure. We simply reduced unnecessary queries.

What This Experience Taught Me

One thing this experience taught me is that backend performance is not always about server power. Sometimes your database is suffering simply because of how you are querying it. A badly written retrieval pattern can quietly destroy performance even when your infrastructure is good. Now whenever I build endpoints, I dont just ask “Does this work?” I also ask “How many queries is this generating behind the scenes?” Because sometimes the biggest backend problem is not the logic. Its the retrieval pattern hiding underneath it. Let me know what you think, thanks for reading, like, share, comment and follow for more.

How I Cut API Response Time from 2s to <100ms with Redis Caching

Ezeana Micheal — Fri, 22 May 2026 15:09:42 +0000

Early in my software development years, I had the opportunity to work with a company where I learned backend development. I worked on a system where I was responsible for building the APIs without senior guidance, just documentation, experimentation, and a lot of self-learning.

When learning to design DB models and RESTful APIs. That was it for me, connect everything and let it out via the get request, let it in via the post request, patch things up with the patch request, and delete via the delete request.

Basic crud operations, and I was fine with that, back then. Eventually, I decided to explore the site myself, and damn, it was slow.

Every interaction came with a noticeable delay. So I stopped assuming things were fine and tested the APIs properly. Using Postman, I measured response times. Most endpoints were taking over 5 seconds.

The Problem

Every request was hitting the database directly, even when requesting the same data repeatedly.

The system wasn’t slow because the database was bad.

It was slow because it was doing the same work over and over again.

What Changed?

I did some research, investigations, and found something powerful. Caching, and utilizing redis for it.

What is Caching?

Caching stores frequently accessed data in memory (Redis uses RAM), allowing much faster retrieval compared to querying a database repeatedly. It reduces database load, instead of hitting the database every time it hits the cache instead and returns the result.

Types of Caching (and Why Redis Fits Here)

Not all caching works the same way. In my case, I implemented application-level caching with Redis, but it helps to understand where it sits in the bigger picture.

1. Application-Level Caching

This is what I used. The application stores frequently accessed data in a fast in-memory store like Redis.

Instead of always asking the database:

API → Database → Response

We first check:

API → Redis → Database (only if needed)

This is the most common approach in backend systems because it gives full control over what gets cached and when it gets updated.

2. Database Caching

Some databases internally cache query results or use external layers to store repeated query outputs.

This reduces repeated expensive queries, but it is less flexible compared to Redis-based caching where you control the logic directly inside your API.

3. Distributed Caching

This is when caching is shared across multiple servers using systems like Redis Cluster or Memcached.

It becomes important when your application is no longer running on a single server, but across multiple services or microservices.

Therefore,

Before:

Client → API → DB (every request)

After:

Client → API → Redis → DB (only on cache miss)

Instead of querying the database every time, the API now checks Redis first. If the data exists, it returns immediately. If not, it fetches from the database, stores the result in Redis, and returns it.

Here was my initial API response time without caching,

Here was my API response time afterwards.

I implemented 2 main strategies.

Key-value Caching.
Cache invalidation via Write.

In my API I implemented key value caching for every get request i.e (get /books/ and get /books/:id)

Eliminating First-Request Slowness (Cache Warm-Up)

One downside of caching is the initial delay when the cache is empty.

How did I solve that? a script.

I added a cache warm-up script that runs on deployment and preloads frequently accessed data into Redis. That way, the system starts “warm,” and users don’t experience the initial latency.

At that point, the only time the system feels slow is immediately after cache invalidation.

But having a cache isn't all good if not invalidated well, because write data comes in too, through post , patch, put. So a cache invalidation strategy was needed.

I chose cache invalidation via Write for 2 reasons:

Data will be refreshed once a put, patch, post or delete request comes in, and
Data is not often changed regularly, the data stays for a while because of the type of application we’re dealing with so giving it a time to live and time to die feels too much.

Trade-offs

Every system has tradeoffs as there is no perfect system. The following were the tradeoffs of my decision.

First request after invalidation is slower
Cache keys must be managed carefully
Slight increase in system complexity

But the system is now significantly faster and more efficient.

PS: There are several optimization techniques in backend development, this article is just about caching.

Thanks for reading, what do you think about the approach? Read, like and comment.

The Bilingual Developer: Python and Go Variables

Ezeana Micheal — Fri, 22 May 2026 14:59:35 +0000

At the heart of programming is a simple idea:

Input -> Processing -> Output

But between input and processing lies something more important, storage.

Before a computer can do anything useful with data, it must first store it somewhere. That “somewhere” is memory. And in programming, the way we interact with memory starts with one core concept:

Variables

Programming is just a way of communicating with a computer, telling it what to store, how to transform it, and what to return.

In this article, we’ll explore how two very different languages, Python and Go, handle the same idea: variables.

Variables: The First Mental Model

A variable is simply a named storage location in memory.

For example (What it does is):

“store the number 10”
“label it as x”
“retrieve it later when needed”

Simple concept, but different languages implement it very differently.

And that’s where Python and Go start to diverge.

Python vs Go: Two Different Philosophies

Python and Go both allow you to store data in variables, but they were designed with different priorities:

Python: flexibility and speed of writing code
Go: structure, safety, and predictability

This difference shows up immediately in how variables are declared.

Dynamic vs Static Typing

Python (Dynamic Typing)

In Python, you don’t explicitly declare the type of a variable:

x=10

Python automatically figures out the datatype at runtime.

This is called dynamic typing.

It gives you flexibility:

You can reuse variables freely
You don’t need to define types upfront
It speeds up development

But the trade-off is that errors may only show up when the program runs.

Go (Static Typing)

In Go, you must define the type explicitly:

var x int = 10

Once declared, the type cannot change.

So this is invalid:

x = "hello" // error

This is called static typing.

It forces structure:

Types are known before execution
Errors are caught early (at compile time)
Code is more predictable in large systems

Two Ways of Declaring Variables

Python keeps it simple:

x = 10

That’s it. One way, one rule.

Go gives you two main approaches:

Explicit Declaration

var x int = 10

### Short Declaration (Walrus-style feel)

x := 10

The := operator tells Go:

“Infer the type automatically, but still lock it in permanently.”

So Go gives you convenience — but never sacrifices structure.

The Concept of “Nothing”

Another major difference is how both languages handle empty or uninitialized values.

Python: `None`

In Python, “no value” is represented explicitly:

x = None

This means:

“This variable exists, but it currently holds nothing.”

It is very explicit and readable.

Go: Zero Values

Go does something different.

If you declare a variable but don’t assign a value, Go automatically gives it a default:

var x int
fmt.Println(x) // 0

So instead of null or None, Go uses zero values:

int → 0
string → ""
bool → false

This design avoids uninitialized variables entirely.

While python thinks: “Let me give you freedom and decide later.” Go thinks: “Let me force clarity so you don’t make mistakes later.”

Even something as simple as variables reveals deep design philosophies:

Python prioritizes developer speed and flexibility
Go prioritizes safety and predictability

Both are correct, just optimized for different worlds:

Python → scripting, AI, automation, rapid development
Go → backend systems, scalability, performance-critical services.

Thanks for reading, what do you think about this? Read, like and comment.

The Bilingual Developer: Learning Python & Go Side-by-Side

Ezeana Micheal — Fri, 15 May 2026 16:50:43 +0000

There are several programming languages and specialized fields today. Navigating the mountain of guides out there can be tricky; some lead you straight into "tutorial hell," while others actually help you gain a solid footing. Python and Go are two of the most popular choices in modern development, different in their own ways, each have their strengths.

I, you, and many others have gone through a tutorial to learn a language one at a time, so I thought of trying something different: Dual-Language Learning. The advantage here is that it gives you two sides of a concept, forcing you to actually understand the underlying mechanisms rather than just memorizing syntax.

Why Python and Go?

Python is a dynamically typed language, which means you can write code, iterate, and test ideas without getting held down in some boilerplate or strict type declarations. It is used for LLM engineering, machine learning, and rapid backend development. Its real power isn't in raw execution speed (it can be slow compared to others), but developer writing speed gives it an edge; it's simpler to write than some other languages. Python serves as the ultimate "glue" language; you write clean, readable code, while the heavy computational lifting is delegated to blazing-fast C++ and Rust kernels under the hood. With industry-standard libraries like PyTorch, Hugging Face, and FastAPI, Python provides the fastest possible path from a raw AI idea to a deployed prototype.

Go (or Golang), developed by Google, is a statically typed language, and the one word I'll use to describe it is speed. It is the industry standard for backend infrastructure, cloud-native tooling (like Docker and Kubernetes), and high-performance microservices, making it a powerhouse for things like high-throughput fintech platforms. While Python historically utilized a Global Interpreter Lock (GIL) that prevented it from running operations concurrently at maximum efficiency, Go handles massive concurrency natively. Through "goroutines," it is blazingly fast at computing simultaneous tasks, allowing it to scale effortlessly across multiple cores.

The 2026 Landscape

Python 3.14: This release officially supports free-threaded Python (allowing you to disable the GIL for true multithreading) and introduces an experimental JIT (Just-In-Time) compiler. It also makes deferred evaluation of type annotations the default, which significantly speeds up startup times.
Go 1.26: The latest release makes the highly efficient Green Tea garbage collector the default (reducing runtime overhead by up to about 40%) and introduces syntax quality-of-life updates, like allowing expressions directly inside the new() function for cleaner pointer creation.

Core Differences

Before learning both languages, you first need to understand how they “think” differently:

How They Run

Python runs your code line by line while the program is executing. This makes it flexible, easy to test quickly, and great for fast development.

Go converts your code into a standalone executable file before it runs. Because of this, Go programs are usually much faster and more efficient.

How Programs Start

In Python, you can usually just write code from top to bottom and run the file.

In Go, every runnable program must follow a fixed structure. You need:

a package main
and a func main() function

That main() function is where the program officially starts running.

Code Style and Formatting

Python gives developers more freedom in how they write and organize code. There are style guides and formatting tools people commonly use, but they are mostly optional.

Go is much stricter. It comes with its own formatting tool called gofmt, and almost every Go developer uses it. This means most Go code looks very similar, making projects easier to read and maintain across teams.

Over the next few weeks, I’ll be writing about Python and Go concepts, sharing code, and seeing what we can learn by comparing them side-by-side. I’d appreciate the support, so let me know what you feel or think about it.

Let's Go Python!

Auth in 2026: What Actually Matters Now

Ezeana Micheal — Mon, 11 May 2026 15:14:47 +0000

With the speed at which Generative AI is being used to build applications, knowing how to code isn't the complete way anymore; understanding what to code is. What is needed? Why is it needed? and more. I’ve decided to take some level of these concepts and explain them to the best of my abilities. Starting with backend development. First, let's understand authentication and authorization concepts.

Authentication is the process of confirming a user’s identity. Basically, it answers “Who is your user?”

Authorization is the process of confirming what a user can do. Basically, it answers “What can your user do?”

In this article, I’ll write about different authentication and authorization methods, what instances they’re used in, and how they work.

But first, we can’t talk about auths without mentioning passwords. Passwords are the most basic authentication method. But it is important to note, NEVER store passwords in plain text. It's the worst mistake any backend developer would make. The idea is to hash the passwords and verify the hash. There are many ways to hash a passwords, but here are 2 to avoid.

MD5
SHA-256

Why avoid them?

These general-purpose hash functions are designed to be fast, and an attacker with a modern GPU can compute millions of SHA-256 per second, making attacks computationally cheap, so when selecting hashing algorithms for passwords, they have to be deliberately expensive or slow. The 2 widely used are Bcrypt and Argon2. Both are designed to be slow and computationally expensive, making it harder for attackers to decipher them through brute-force attacks.

Bcrypt was designed in 1999; it is based on the Blowfish cipher and uses a salt to protect against rainbow table attacks. It also incorporates a cost factor that quantifies the hash's computational cost. The cost doubles with each increment, i.e., cost 10 is twice as expensive or hard as cost 9 was.

Argon2 was introduced in 2015 as the winner of the Password Hashing Competition. The edge it has over bcrypt is that it has resistance to side-channel attacks. You can read more on it later.

We will consider the following authentication methods:

JWT Authentication
Session-Based Authentication
OpenID Connect Authentication
MFA (Multi-Factor Authentication)
SSO (Single Sign-On)
Passkeys / WebAuthn (FIDO2)
API keys

And the following authorization methods:

OAuth 2.0
RBAC(Role-Based Access Control)
ABAC(Attribute-Based Access Control)

Starting with authentication,

JWT Authentication

Json Web Token(JWT) is a compact, URL-safe token that encodes a set of claims (key-value pairs) and is cryptographically signed. A unique feature is that JWTs enable stateless authentication; the signature is verifiable without a database lookup. The server can validate the token with just the secret key.

A JWT has 3 Base64URL-encoded parts separated by dots: Header, Payload, and Signature.

a. Header contains the algorithm and the type e.g

{ "alg": "HS256", "typ": "JWT" }

b. Payload contains the encoded claims, e.g

{

"sub": "user_id_123",

 "email": "mike@synoloop.com",

 "role": "admin",

 "iat": 1716000000,    // issued at (Unix timestamp)

 "exp": 1716003600     // expires at (1 hour later)

}

c. The signature is the encrypted base64url header and payload with the secret.

In real-world authentication systems, JWTs are most commonly used in two forms: Access tokens and refresh tokens.

Access tokens are short-lived, between 5 and 15 minutes. Refresh tokens, on the other hand, are long-lived from days to even weeks and are used to obtain new access tokens without reauthenticating (depending on the developer).

But what happens if a token is stolen or a user logs out of the system? Since JWTs are stateless and valid until they expire, we need a way to invalidate them before their natural expiration. This is where token blacklisting comes in.

This is solved by maintaining a server-side denylist. Once any of the above events happen, the JWTID is added to the blacklist.

So on logout or password change or compromise, it's best to revoke or blacklist all existing refresh tokens. This logs out the user on all sessions. On each request, the server looks up the session ID, retrieves the session data, and authenticates the user.

Session-Based Authentication

Session-based authentication stores the auth state on the server, so when a user logs in, it creates a session record and stores it. What makes Sessions different from JWTs is that Sessions are easier to revoke immediately, but require server-side storage. JWTs are stateless but harder to invalidate before expiry.

In sessions, it's best to always regenerate the session ID after login to prevent session fixation attacks.

OpenID Connect (OIDC) Authentication

OIDC is an identity layer built on top of OAuth 2.0(Will be discussed in authorization). OIDC answers who this user is. It adds a standardized ID token(a JWT) containing identity claims.

Think of this as when you use any web application that has a “continue with Google”; this sends your name, email, phone (and other details if requested) from Google to the web application authorized, answering who you are.

It gives the addition of what an OAuth 2.0 gives.

ID Token: a JWT containing user identity (sub, email, name, picture, etc.)
UserInfo Endpoint: returns additional claims about the authenticated user
Discovery Document: /.well-known/openid-configuration for automatic configuration
Standard Claims: sub (subject/user ID), email, email_verified, name, picture

MFA( Multi-Factor Authentication)

Multi-factor authentication requires users to have two or more verification factors present: something they know (password), something they have (phone/hardware key), and something they are (biometric).

Multi-factor authentication includes methods like TOTP and Backup Codes.

TOTP(Time-Based One-Time Passwords), generates a 6-digit code that changes every 30 seconds based on a shared secret and the current time. It works with apps like Google Authenticator, Microsoft Authenticator, and such.
Backup Codes: These are a list of 8 to 10 single-use random codes that can be used to retrieve the account or authenticate.

SSO(Single Sign-On)

Single Sign-On allows users to authenticate once and gain access to multiple systems. This is mostly used in enterprise environments or applications; the 2 main protocols are SAML 2.0 (XML-based, older) and OIDC-based SSO (modern, JSON/JWT-based).

SAML is the standard in enterprise environments (corporate identity providers like Okta and Azure). It uses XML assertions to tell the identity. The identity provider (IdP) authenticates the user and sends a signed XML assertion to the service provider (SP).

Service Provider (SP) is your application
Identity Provider (IdP) is Okta, Azure, Google Workspace, etc.
An assertion is a signed XML document asserting identity and attributes.

Passkeys / WebAuthn (FIDO2)

Passkeys are an advanced form of authentication: passwordless, phishing-resistant, and cryptographically strong. Based on the WebAuthn standard (W3C) and FIDO2 protocol, they use public-key cryptography with biometrics or device PINs.

Passkeys have become popular since their release in 2018. They work in 2 major steps:

Registration: The browser or the device generates a public/private key pair. Private key stays on the device. The public key is sent to your server.
Authentication: Server sends a challenge. The device signs the challenge with the private key. The server verifies with the stored public key.

No Password is ever transmitted or stored, and attackers can’t do anything with just the public key.

API keys

I chose to keep API keys under authentication, but underneath, they do both authentication and authorization; I’ll explain.

API keys are Opaque tokens issued for programmatic access to services, scripts or public-facing APIs.They should be scoped, rotatable, and auditable.

API keys act like a username and password pair, but simplified. They identify the calling application or developer. For example, A weather API requires an API key to ensure only registered apps can access data.

While some APIs use keys with scoped permissions (e.g., read-only or read and write).

Example: A developer can generate API keys in a payment app and may allow one key to process transactions but another only to view reports.

Some design principles of API keys include:

Including a prefix for easy identification (e.g., sk_live_, sk_test_, syno_)
Generate with cryptographically secure randomness (at least 128 bits)
Store only the hash in your database, treat keys like passwords
Support scopes/permissions per key
Log all usage with timestamps for auditing
Support rotation: allow multiple active keys per user, then invalidate old ones

Now, let's consider the authorization concepts:

OAuth 2.0

This is an authorization framework that allows a third-party application to obtain limited access to a service on a user's behalf without exposing credentials. You can think of this as “connect to GitHub” or authorizing Google Drive access via a “connect to Google.” It's about what you can access, not about who you are.

RBAC(Role-Based Access Control)

RBAC Controls access by assigning permissions to roles, and roles to users. This is most common in authorization models for web applications. User has a role, and the role has permissions. For example, in an e-commerce application. There are key roles like Admin, Vendor, and User. Each of these roles has different permissions. Admin can read all users and vendors, edit or verify, or ban a vendor. The vendor can upload products, the user can read and purchase products.

ABAC(Attribute-Based Access Control)

ABAC is another authorization method. It evaluates attributes of the user, the resource, the action, and the environment to make an authorization decision. For example, consider that a manager can edit a document only if they are in the same department as the document's owner, during business hours. We can see that many conditions affect the action that can be carried out by the manager.

When to Use ABAC vs RBAC

Use RBAC when access rules map cleanly to roles and don't depend on resource data
Use ABAC when you need fine-grained rules like row-level security, ownership checks, or time-based restrictions
Many systems use both: RBAC as a coarse gate, ABAC for fine-grained resource access

This is the conclusion of my article. We’ve considered various authentication and authorization concepts.

Please show your appreciation by giving this a like, leaving a comment with something encouraging, or sharing something you just learned, or something I may have gotten wrong. Thanks for reading.

LegalCheck: Built for freelancers and remote workers after an issue I ran into.

Ezeana Micheal — Sat, 28 Feb 2026 18:28:27 +0000

This is a submission for the DEV Weekend Challenge: Community

The Community

I built LegalCheck for freelancers, startup founders, indie builders, and non-legal tech practitioners who sign contracts without fully understanding what they’re agreeing to.

In places like Nigeria, legal support isn’t always accessible or affordable. A lot of people copy templates from the internet, sign client agreements quickly, or accept vendor contracts under pressure without truly knowing the risks(like me once before).

LegalCheck is for that community. The builders. The side-hustlers. The agency owners. The developers. The designers. The people shipping fast but still needing protection.

I’m built(and am still scaling) this for people like me.

What I Built

LegalCheck is an AI-powered contract analysis tool.

You upload a contract.
It reads it.
It highlights risky clauses.
It explains them in plain English.

No legal jargon. No intimidation.

What it does:

Analyzes contracts (freelance agreements, NDAs, service contracts, etc.)
Flags risky or one-sided clauses
Explains complex legal language in simple terms
Highlights missing protections
Breaks down what each key clause actually means for you

It doesn’t replace a lawyer.
It gives you clarity before you sign.

And that alone can save people from very expensive mistakes.

Demo

legalcheck.buildswithmike.com

(It takes some time to scan the contract about 5-10 mins, but it'll be worth the wait)

Code

Just-Mike4 / legal-check

AI-Legal Contract Analyzer

LegalCheck - AI-Powered Legal Document Analysis

LegalCheck is an intelligent legal document analysis platform that extracts, identifies, and explains specific clauses in legal documents. It translates complex legal language into plain English and provides visual representations where helpful.

Features

Instant Clause Detection: Automatically identify all key clauses in legal documents
Plain English Explanations: Complex legalese translated to simple language
Risk Assessment: Identify potentially risky clauses with severity levels
Visual Representations: Timelines and flowcharts for complex terms
Document Comparison: Compare clauses across similar documents
Q&A System: Ask questions about specific clauses

Tech Stack

Backend: Flask, SQLAlchemy
Authentication: Google OAuth (Authlib)
AI/ML: Google Gemini AI for clause analysis
Document Processing: pypdf, python-docx, pytesseract (OCR)
Frontend: Tailwind CSS, Vanilla JavaScript
Database: SQLite (development), PostgreSQL (production)

Setup Instructions

Prerequisites

Python 3.9 or higher
Google OAuth credentials
Gemini API key
Tesseract OCR (for…

View on GitHub

How I Built It

I built LegalCheck using Flask for the backend, Jinja2 for templating, Tailwind CSS for UI, and Google GenAI (Gemini 2.5) for the contract analysis.

Thanks for Reading!.

Custom QuerySets in Django: Writing Cleaner, Reusable Queries

Ezeana Micheal — Sat, 20 Sep 2025 07:38:57 +0000

Custom QuerySets in Django: Writing Cleaner, Reusable Queries

When building Django applications, especially as they scale when creating views and similar components, it's easy to find yourself using the same queries repeatedly in different logical steps. The repetition makes the code hard to maintain and can cause some confusion.

This is where querysets come in. Custom querysets allow us to write cleaner code, keeping some business logic close to your models while avoiding duplication.

But first, what is a queryset?

A queryset is simply a collection of database queries in Django, it allows us to make queries through Django’s ORM to the database. By default, objects is Django’s built-in Manager that returns a QuerySet. But what if you always need the query? Rewriting the filter everywhere does not follow the DRY (Don’t Repeat Yourself) principle.

from blog.models import Post

# Default QuerySets  
all_posts = Post.objects.all()  
published_posts = Post.objects.filter(status="published")

Now, let's get into the programming aspect. How do you define a custom queryset? We use the models imported from Django’s DB and inherit from the Queryset. Here’s an example, Suppose you have a Post model and you want to make some repeated queries.

from django.db import models

class PostQuerySet(models.QuerySet):  
    def published(self):  
        return self.filter(status="published")

    def drafts(self):  
        return self.filter(status="draft")

    def by_author(self, author):  
        return self.filter(author=author)

Let's now attach this to our model.

class Post(models.Model):  
    STATUS_CHOICES = (  
        ("draft", "Draft"),  
        ("published", "Published"),  
    )

    title = models.CharField(max_length=200)  
    content = models.TextField()  
    status = models.CharField(max_length=10, choices=STATUS_CHOICES)  
    author = models.ForeignKey("auth.User", on_delete=models.CASCADE)

    # Attach the custom QuerySet  
    objects = PostQuerySet.as_manager()

Now we can make queries like

# All published posts  
Post.objects.published()

# All drafts by a specific author  
Post.objects.drafts().by_author(user)

We can even chain them,

# Get published posts by a specific author  
Post.objects.published().by_author(user)

In a way, querysets and managers are similar and different. How would you know when to use either?

Use Custom QuerySets when:

You want reusable filters (like .published(), .active()).
You need chainable queries.

Use Custom Managers when:

You want to override get_queryset() itself.
You need queries that return something other than a QuerySet (like creating objects or aggregations).

In this article, We’ve seen how qureysets helps us in keeping the DRY principle and writing cleaner code, in the next one we’ll consider when and how the 3 powerhouses in our models.py can be used together in Custom Model Methods vs. Managers vs. QuerySets: When to Use Each.

Understanding Django Managers: The Gateway to Your Data

Ezeana Micheal — Sat, 13 Sep 2025 12:53:06 +0000

When working with Django models, you’re not just defining tables, you’re also defining how to interact with them. In this article, we’re going to use one of Django’s powerful tools when making queries, which is Django managers. Django managers define the interface for the interaction between your code and the database. The default one most are used to is the “objects” as in “students.objects.all()”.

Examples;

class Student(models.Model):  
    name = models.CharField(max_length=100)  
    age = models.PositiveIntegerField()

# Using the default manager  
all_students = Student.objects.all()  
adults = Student.objects.filter(age__gte=18)

Creating a Custom Manager

Alongside this default manager, we can also create custom managers. But why would we need to do so?

While objects is useful when performing basic queries, when dealing with larger projects, custom managers give user-defined reusable logic in code. Let's look at a practical example of this by using Django’s models. We then define a class that inherits from it and overwrites the get_queryset method in the student manager.

class ActiveStudentManager(models.Manager):  
    def get_queryset(self):  
        return super().get_queryset().filter(is_active=True)

class Student(models.Model):  
    name = models.CharField(max_length=100)  
    is_active = models.BooleanField(default=True)

    objects = models.Manager()        # Default manager  
    active = ActiveStudentManager()   # Custom manager

How then do you use this custom manager? Look below,

Student.objects.all()   # returns all students  
Student.active.all()    # returns only active students

Adding Custom Methods to Managers

You can also add methods to model managers to perform specific actions or queries. An example is sorting students by age group.

class StudentManager(models.Manager):  
    def teenagers(self):  
        return self.filter(age__gte=13, age__lte=19)

    def adults(self):  
        return self.filter(age__gte=18)

class Student(models.Model):  
    name = models.CharField(max_length=100)  
    age = models.PositiveIntegerField()

    objects = StudentManager()

Then using,

Student.objects.teenagers()  # all students aged 13–19  
Student.objects.adults()     # all students aged 18+

Multiple Managers in a Model

As seen in the first example, you can add more than 1 manager to a model to ease and streamline usage.

class ActiveStudentManager(models.Manager):  
    def get_queryset(self):  
        return super().get_queryset().filter(is_active=True)

class Student(models.Model):  
    name = models.CharField(max_length=100)  
    is_active = models.BooleanField(default=True)

    objects = models.Manager()        # Default manager  
    active = ActiveStudentManager()   # Custom manager

Managers vs. QuerySets

Managers are not qureysets. Managers are entry points to the database while QuerySets represent the actual collection of records. In the next article, we’ll see how we can use Querysets.

Multiple Managers in a Model

A model can have multiple managers, but they have one default manager, which is the objects; this can be subject to change, though.

class Student(models.Model):  
    name = models.CharField(max_length=100)  
    is_active = models.BooleanField(default=True)

    objects = models.Manager()       # default  
    active = ActiveStudentManager()  # custom

NOTE: The default manager is used in admin and migrations, so always keep objects = models.Manager() unless you know what you’re doing.

We have seen how Django managers can be used in this article, and how they help in holding some business logic and reusable queries. In the next article, we will explore querysets in Django and how they are used alongside this.

ForeignKey vs ManyToMany vs OneToOne: When to Use Each in Django

Ezeana Micheal — Sat, 06 Sep 2025 07:21:35 +0000

In common Relational Database concepts, relationships between tables are nothing new; these help to represent connections between tables and link them together. In this article, I’ll explore some common DB relationships and how they are used in Django. These include One-to-One, One-to-Many (foreign key), and Many-to-Many Relationships.

One to One

In a one-to-one relationship, one record in a model corresponds exactly to one record in another model. For example, a user’s relationship to his profile, using Django’s built-in user model, we can extend by creating a user profile:

from django.contrib.auth.models import User

class Profile(models.Model):  
    user = models.OneToOneField(User, on_delete=models.CASCADE)  
    bio = models.TextField()  
    birth_date = models.DateField(null=True, blank=True)

One to Many

In a one-to-many relationship, one record in a model corresponds to many records in another model. This means a record in a table can be linked to multiple records in another table, and this is done using a foreign key. A practical example of this is of an author having many books.

from django.db import models

class Author(models.Model):  
    name = models.CharField(max_length=100)

class Book(models.Model):  
    title = models.CharField(max_length=200)  
    author = models.ForeignKey(Author, on_delete=models.CASCADE)

Many to Many

In a many-to-many relationship, a table is linked to another table where multiple records in one table are related to various records in the other. An example is a relationship between students and courses. A student can enroll in many courses, and a course can have many students.

class Student(models.Model):  
    name = models.CharField(max_length=100)

class Course(models.Model):  
    title = models.CharField(max_length=200)  
    students = models.ManyToManyField(Student)

In each of these types of relationships in Django, there are some common parameters and their meaning.

On_delete: In a foreign key and the one-to-one field, there’s the on_delete parameter.

The common options are:

models.CASCADE: delete related objects too.
models.SET_NULL: set field to NULL (requires null=True).
models.PROTECT: prevent deletion if related objects exist.
models.SET_DEFAULT: set field to default value.
Related_name: This defines the name used to access the reverse relationship; without this, Django automatically adds _set, i.e, (model_name)_set.

   class Course(models.Model):  
       title = models.CharField(max_length=200)  
       students = models.ManyToManyField(  
           "Student",   
           related_name="enrolled_courses"  
       )  

   #referenced here using  

   student = Student.objects.first()  
   student.enrolled_courses.all()  # instead of student.course_set.all()

blank and null: Blank and Null are boolean parameters; null=True means the database can store NULL values, while blank=True means validation allows empty values.

   class Profile(models.Model):  
       bio = models.TextField(blank=True, null=True)

Through: This is unique for the many-to-many field, it lets you define a custom intermediate model for many-to-many relationships.

   class Enrollment(models.Model):  
       student = models.ForeignKey("Student", on_delete=models.CASCADE)  
       course = models.ForeignKey("Course", on_delete=models.CASCADE)  
       enrolled_at = models.DateTimeField(auto_now_add=True)  
       grade = models.CharField(max_length=2, blank=True)  

   class Course(models.Model):  
       title = models.CharField(max_length=200)  
       students = models.ManyToManyField("Student", through="Enrollment")  

   # usage below  
   student = Student.objects.first()  
   course = Course.objects.first()  
   Enrollment.objects.create(student=student, course=course, grade="A")

From this article, we’ve been able to break down relationships in Django, their parameters, and how they’re referenced. Next, we’ll move into understanding Django managers.

Designing Better Django Models: Tips for Scalability and Clarity

Ezeana Micheal — Sat, 30 Aug 2025 10:05:17 +0000

I’ve been using Django for a while now, and I’ve seen countless guides on how to write better code, structured code, and the list goes on. I decided to write mine to cover one major aspect, which is simplicity, for this guide, and following ones, I'll make use of simple wordings and easy to understand python code that can guide you (or anyone) in writing simple and powerful django applications, and to start with, the models, which are the backbone of traditional backend applications, a poorly written model design will cause a lot of problems in your application like optimization and scaling difficulty, lets explore practices and use cases, for this article ill make use of a blog model to explain the process. To begin, we start with defining a clear data model.

Start with a Clear Data Model

Before you start writing code, it is essential to understand what you want the code to do first. It's always best to get a clear picture of what you want your database to look like through design, including the relationships. Tools like Draw.io can help with that. (This article won't cover how to design your model; it's more on writing code using Django)

After designing your database and relationships, we're ready to hop into the code. Keep 2 things in mind: naming matters, and keep models simple. For example, here's our post model.

from django.db import models  
class Post(models.Model):  
    title = models.CharField(max_length=255)  
    content = models.TextField()  
    published_at = models.DateTimeField(auto_now_add=True)

It's always best to use meaningful, singular model names like Post, not Posts, and we limit it to 3 fields: title, content, and published date. Next, let's look at choosing the right type of fields.

Choosing the Right Field Types

In Django’s models, there are several field types like CharField, TextField, and DateTimeField used in the above, but aside from this, there are others like URLField, EmailField. Let's take a look at the user profile table below:

class UserProfile(models.Model):  
    email = models.EmailField(unique=True)     
    website = models.URLField(blank=True)  
    bio = models.TextField(blank=True)  
    reputation = models.DecimalField(max_digits=6, decimal_places=2, default=0.00)

It's always best to use a specific field for some of the following reasons:

Django provides built-in validation
Helps Django’s retrieval from the database
It saves space and optimizes in the database (e.g, using Charfield for fields like name with a max length set, rather than a text field, which is better suited for description)

Now, let's consider primary keys and identifiers.

Primary Keys & Identifiers

When talking of primary keys, we consider the IDs of these tables since these are what link them up. It also brings up the question, when it is best to use Django’s default ID and a UUID.

By default, Django creates an ID this way:

id = models.BigAutoField(primary_key=True)

It auto-increments, and it's useful for small to medium-scale projects. The downside of this is that it's predictable, and it can expose user count or allow enumeration attacks in APIs.

UUIDs, on the other hand, are especially useful in distributed systems or microservices, where you can’t rely on a central database to generate sequential IDs.

import uuid  
class UserProfile(models.Model):  
    id = models.UUIDField(primary_key=True, default=uuid.uuid4, editable=False)  
    email = models.EmailField(unique=True)

UUIDs are harder to guess and good for public-facing URLs, but they require larger storage and are slower to index. Let's take a step into relationships.

Relationships Done Right

In Django, there are 3 major types of relationships: one-to-one, one-to-many (Foreign key), and many-to-many. Below are examples of such relationships.

class Post(models.Model):  
    author = models.ForeignKey("Author", on_delete=models.CASCADE, related_name="posts")  
    title = models.CharField(max_length=255)  
    content = models.TextField()

class Comment(models.Model):  
    post = models.ForeignKey("Post", on_delete=models.CASCADE, related_name="comments")  
    author = models.CharField(max_length=100)  
    body = models.TextField()

class Tag(models.Model):  
    name = models.CharField(max_length=50, unique=True)  
    posts = models.ManyToManyField("Post", related_name="tags")

models.Foreignkey, models.ManyToMany and models.OneToOne.

You’ll notice related name parameter placed in these relationship, it is the reverse relation name Django will use when looking up related objects.

For example:

post = Post.objects.first()  
post.comments.all()   # instead of post.comment_set.all()

The on_delete argument tells Django what to do with related objects when the referenced object is deleted. In our case models.CASCADE means delete the dependent rows too. This is important so it doesnt retain dependent roles in the database.

Model Methods & Business Logic

When writing business logic in the model.py file, we must ensure that this is not where all our methods should be; basically, just simple and commonly used logic can be implemented here, for example, using sample model methods.

class Post(models.Model):  
    title = models.CharField(max_length=255)  
    content = models.TextField()  
    published_at = models.DateTimeField(auto_now_add=True)

    def is_published_recently(self):  
        from django.utils import timezone  
        return self.published_at >= timezone.now() - timezone.timedelta(days=7)

The post.is_published_recently() can now be called and works as intended from here.

Performance Considerations

Finally, for some performance considerations, here are some tips: use indexes for frequent lookups; they query faster.

class BlogPost(models.Model):  
    slug = models.SlugField(unique=True, db_index=True)

Keeping Models Maintainable

Utilizing some built-in functions in Django models to help readability and reusability is mostly advised, adding str for readability, adding a class meta for verbose name, and ordering.

class Post(models.Model):  
    title = models.CharField(max_length=255)  
    body = models.TextField()  
    created_at = models.DateTimeField(auto_now_add=True)

    Class Meta:  
        ordering = ["-created_at"]  
        verbose_name = "Blog Post"

    def __str__(self):  
        return self.title

From this article, we’ve seen the need for simplicity in creating Django models and utilizing functionalities to optimize performance. In the next article, we’ll consider in-depth the use of foreign keys, one-to-one and many-to-many.

Distributed Systems: Designing Scalable Python Backends

Ezeana Micheal — Mon, 27 Jan 2025 07:08:27 +0000

Almost all systems today connected through the World Wide Web are distributed systems. Distributed systems are a group of multiple computers or servers that work together and functionalize optimally. This allows multiple users to utilize such software or services without facing slow loading times and poor performance. For example, imagine you build a website and host it on a single-user server, this would perform well until user traffic increases, demanding more resources and speed. Distributed systems aid performance and flexibility by splitting the application into individual services on separate servers that interact with each other. This would seem like a simple software or application to the user, but on the backend, it's multiple interconnected nodes talking to each other.

Python programming language is one of the slowest, but one of the most useful languages today, ever since the advent of artificial intelligence, machine learning, and Large Language Models, python has been the go-to language for these, but no one wants a chatbot or an ml service that takes a long amount of processing time to work, distributed systems is a key to optimizing such on an application. In this article, we’ll consider key features of distributed systems, why you should use distributed systems, and how we can scale a distributed system with Python.

Key Features Of Distributed Systems

The following are key features of distributed systems that make them work optimally:

Nodes: Individual computers or processes that work together as part of the system; each node performs certain tasks and connects with others to ensure the system functions properly.
Communication Protocols: Nodes can communicate and share information thanks to protocols like HTTP, gRPC, or TCP/IP, which guarantee dependable communication between components even when they are on different networks.
Shared Resources: Distributed systems frequently rely on resources like databases, file systems, or message queues; proper management enables consistent and efficient access across all nodes.
Fault Tolerance: Even if a node fails, distributed systems continue running, eliminating a single point of failure. Redundancy and replication techniques ensure reliability and high availability.
Scalability: The ability to handle increased load by adding more nodes (horizontal scaling) or enhancing the capacity of existing nodes (vertical scaling). Scalability ensures the system remains responsive under high demand.

Why Scalability Matters?

Scalability as mentioned earlier is a system’s ability to handle increased load by adding resources. This ensures the system is always at optimal performance during traffic spikes. There are 2 major types of scaling:

Horizontal scaling: This involves using more machines and servers for the application to work smoothly.
Vertical scaling: This involves increasing the system's RAM, storage, and capacity.

How to Design Scalable Python Backends

Knowledge of the right tools is required to design scalable Python backends to allow the system to grow and remain efficient. Below are some key tools and strategies for building scalable Python backends.

APIs: Use lightweight frameworks like Flask or Fast API to build scalable backend APIs. They are relatively easy to use when creating rest APIs. Fast API is best for performance and its support for asynchronous programming.
Asynchronous processing: To support the main application, it is wise to offload some background tasks(like emails or data processing) using Cerely with Redis as the message broker.
Load Balancing: To balance the load or traffic on the application, distribute incoming requests evenly across backend servers like Nginx or HAProxy in the distributed system.

Example: A task queue with Celery and Redis.

# tasks.py
from celery import Celery

app = Celery('tasks', broker='redis://localhost:6379/0')

@app.task
def process_order(order_id):
    print(f"Processing order {order_id}")

# Adding a task to the queue
process_order.delay(123)

Data Management in Distributed Systems

Maintaining the CAP theorem or properties when managing data in distributed systems.

Consistency: All nodes in the distributed system see the same data. If data is updated in a node, all nodes should reflect the updated value immediately.
Availability: The system responds even during a node failure. The system should always be operational.
Partition Tolerance: It should work despite network failures between nodes.

Useful databases are:

SQL Databases like PostgreSQL for transactional consistency.
NoSQL Databases like MongoDB for scalable, flexible schemas.

An example is a case setting up a distributed MongoDB cluster to store and retrieve user data across multiple nodes, ensuring high availability and fault tolerance.

Tools for Deployment and Scaling

Deployment and scaling are when tools like docker and Kubernetes come in.

Docker: Docker is used to containerize Python backend applications for consistent environments.
Kubernetes: This helps automate the deployment, scaling, and management of the containerized application.

Example: Below is a simple/basic example of deploying a Python backend application using docker and Kubernetes.

Dockerfile:

 FROM python:3.10
WORKDIR /app
COPY . .
RUN pip install -r requirements.txt
CMD ["python", "app.py"]

Kubernetes Deployment:

 apiVersion: apps/v1
kind: Deployment
metadata:
  name: flask-backend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: flask-backend
  template:
    metadata:
      labels:
        app: flask-backend
    spec:
      containers:
      - name: flask-backend
        image: flask-app:latest
        ports:
        - containerPort: 5000

Monitoring and Maintenance

In distributed systems, it is important to monitor and maintain nodes around the system as they interact and function as one. This will help to identify and fix possible faults.

Examples of tools that do this are Prometheus and Grafana.

Prometheus: Prometheus helps to collect metrics on API performance, database latency, etc.
Grafana: Grafana visualizes metrics with customizable dashboards.

Case Study: Scalable Ecommerce Backend

Before I conclude this article, let's look at how to apply distributed systems during the development of an e-commerce system.

FastAPI can be used for the backend system and handle API’s for order processing.
Celery with Redis is used to handle asynchronous background processing of tasks like payments or inventory updates.
The application is deployed on docker and Kubernetes to ensure the scaling of the system.
The application is monitored using tools like Prometheus.

Conclusion

By using Python tools like Flask, FastAPI, Celery, Docker, and Kubernetes, developers can build robust and scalable systems. In this article, we’ve covered the general terms related to distributed systems and how they can help, as well as some basic examples with Python. You can do advanced research on these tools and how they can work together and help. Start experimenting with these tools and create backends that can handle the challenges of real-world traffic and growth. Happy hacking.

DEV Community: Ezeana Micheal

The Bilingual Developer: Python and Go Primitive Data Types

Understanding Primitive Data Types

Text and Characters

Strings in Python

Strings and Runes in Go

Numbers

Integers and Floats in Python

Integers and Floats in Go

Booleans

Booleans in Python

Booleans in Go

Constants

Constants in Python

Constants in Go

Conclusion

The N+1 Query That Killed Our Database, And How I Fixed It

Everything Worked…But Not Well

What Actually Is The N+1 Query Problem?

A Simple Example

Why This Problem Is Dangerous

The Mistake We Made

Understanding select_related()

Understanding prefetch_related()

The Difference Between select_related() And prefetch_related()

select_related()

prefetch_related()

The Result

What This Experience Taught Me

How I Cut API Response Time from 2s to <100ms with Redis Caching

The Problem

What Changed?

What is Caching?

Types of Caching (and Why Redis Fits Here)

Therefore,

Eliminating First-Request Slowness (Cache Warm-Up)

Trade-offs

The Bilingual Developer: Python and Go Variables

Variables: The First Mental Model

Python vs Go: Two Different Philosophies

Dynamic vs Static Typing

Python (Dynamic Typing)

Go (Static Typing)

Two Ways of Declaring Variables

Explicit Declaration

The Concept of “Nothing”

Python: None

Go: Zero Values

The Bilingual Developer: Learning Python & Go Side-by-Side

Why Python and Go?

The 2026 Landscape

Core Differences

How They Run

How Programs Start

Code Style and Formatting

Auth in 2026: What Actually Matters Now

Why avoid them?

JWT Authentication

Session-Based Authentication

OpenID Connect (OIDC) Authentication

MFA( Multi-Factor Authentication)

SSO(Single Sign-On)

Passkeys / WebAuthn (FIDO2)

API keys

OAuth 2.0

RBAC(Role-Based Access Control)

ABAC(Attribute-Based Access Control)

When to Use ABAC vs RBAC

LegalCheck: Built for freelancers and remote workers after an issue I ran into.

The Community

What I Built

Demo

Code

Just-Mike4 / legal-check

AI-Legal Contract Analyzer

LegalCheck - AI-Powered Legal Document Analysis

Features

Tech Stack

Setup Instructions

Prerequisites

Understanding `select_related()`

Understanding `prefetch_related()`

The Difference Between `select_related()` And `prefetch_related()`

`select_related()`

`prefetch_related()`

Python: `None`