DEV Community: Emmaculate Jane Akinyi Odhiambo

Monolith vs Microservices

Emmaculate Jane Akinyi Odhiambo — Sun, 27 Sep 2026 09:20:27 +0000

A very small bag in one part of your application just brought everything down. Login, down. Payments, down. Search, down. How can one tiny bag bring down an entire application? Let's imagine we're building an online store. Login, payments, search, notification, products, all that. At first, we'll put everything into one application, and everything runs in that one application. This is called a monolith. It's not necessarily bad. It's simple to build, deploy, and even test. But imagine the notification system has a bag, and it crashes the entire application process. Now, login goes down, payments go down, search goes down, not because they are broken, but because they are all running together. So what if we split the application? Login becomes one service, payment, another, search, another, notifications, another service. Now, each service is running independently. This is microservices. These services won't run inside one application process. They communicate over a network. For example, the order service might call the payment service to process a payment. So what does this mean? If notification clashes, then it means login can still keep running, payments can still keep running. And if such is getting heavy traffic, you only have to scale such.

And that right there is the power of microservices. But microservices aren't free. You've basically treated the application simplicity for a distributed system complexity. And now you have network failures, timeouts, retries, monitoring, logging, and now you're debunking across multiple services. A simple function call can become a network request that might fail. You might be asking, so which one is better? Neither of them. Monolids are simpler and often the right choice for smaller systems. Microservices makes sense when you need independent scaling, independent deployments, or strong isolation. So don't build 20 services just because microservices sounds better. Start simple, find the problems, then split the system when you actually need to. Because at the end of the day, good architecture isn't just using the most advanced technology. It's about solving the problems you actually have. So monolith first, microservices when you actually need them.

Kubernetes, without confusing Jargon

Emmaculate Jane Akinyi Odhiambo — Sun, 27 Sep 2026 09:17:30 +0000

Remember those containers we created with docker one container easy to manage but imagine your application is running hundreds of them, some can crush, traffics increases and you need more containers and they're are running across different computers. So who manages all of these, that's where Kubernetes comes in.

Here is the thing, Docker is great at packaging and running containers BUT docker doesn't decide which computer these containers should run on. It doesn't automatically manage what happens when a container crushes, it doesn't even scale your application when traffic suddenly increases.

Docker builds the box but it doesn't manages 100 boxes spread across different containers. Something else has to do that and that's Kubernetes

So let's build this app, one problem at a time. First problem you have a container and it has to run on an actual computer somewhere, Kubernetes is design to spread your containers across multiple computers each of those computers are called a node.

A node could be a physical server running in a Data center or a virtual machine running in the cloud. Simply put A Node is a computer that Kubernetes can use to run your application. Put the container on a node problem solved right. Not quite Kubernetes needs to do things with your application restart it if crashes, replace it if it falls, move it to another node if the current node goes down. If Kubernetes only knew about a raw container it wouldn't have an easy way to manage all of that so Kubernetes can wrap your container in something it actually understands. That trapper is called a POD.

Technically, a pod is the smallest deployable units that Kubernetes manages simply put a pod is a pod is the unit that Kubernetes uses to run and manage your containers. Most of the time a pod contains one application container but a pod can also contain multiple containers especially when they need to work closely together.

A node is a computer and a pod runs on that computer. One node can run several pods at the same time so you might have one node running several pods and another one running even more so Kubernetes manages where these pods will run. But there's a problem, if one node goes down every pod running on it goes down your application cannot just depend on one computer. Kubernetes doesn't just manage one node, it manages multiple of them working closely together. That group of nodes is a cluster, simply put a Kubernetes cluster is a group of computers which we call nodes that are being managed by Kubernetes.

If one node fails Kubernetes creates a replacement pod and then run this replacement pod on other nodes. lets recap the cluster is the overall Kubernetes environment, inside the cluster are nodes which are the computer that provides the resources those nodes runs pods and those pods runs your application containers.

Now we understand the structure, let's see what Kubernetes actually does. Let's say you tell Kubernetes i want three pods running everything is fine. You have three pods and then one crashes without Kubernetes you might have to notice the problem and fix it yourself. But Kubernetes continuously monitors the state of your application. It knows you wanted three pods but now they are two, so Kubernetes creates a replacement until you have three pods again. This is one of the ideas behind self healing.

Now imagine traffic suddenly increases, three pods might not be enough. Kubernetes can also help with scaling instead of running three pods you can run 10, 50 or 100 depending on your application and the available resources and when demand decreases the number of pods can be reduced again, this is called Scaling and when systems automatically adjust the number of pods depending on demand that's called Auto-Scaling.

But here's another problem, If Kubernetes creates new pods where should they run remember the nodes from earlier; Kubernetes has a component called a Scheduler. So it's job is to decide which node should run a new pod it considers things like available CPU, available memory and rules that you've configured. So if a node is already bu9st Kubernetes places the new pod inside node 2, which eventually helps distributing workload across the cluster.

So the next time here this application runs on a Kubernetes, picture a cluster with multiple nodes and those nodes runs multiple pods and the pods run your application containers

In summary Docker helps you package and run your applications inside containers. Kubernetes on the other hand takes those containers manages them through pods places these pods inside nodes and organizes these nodes inside a cluster. It can restart pods when they fail, scale them when demand changes and schedule them across your available nodes. Kubernetes is all about managing your containers but at scale.

Vibe coding isn't the hardest part anymore

Emmaculate Jane Akinyi Odhiambo — Sun, 27 Sep 2026 08:39:11 +0000

You know what nobody tells you about vibe coding? You can build an entire app in a few hours, but then you launch it and nobody cares. And honestly, I think that's becoming the bigger problem with vibe coding because building is getting easier. You can have an idea, open cloud or Casa, describe what you want, and boom, you have an app. But, having an app doesn't mean you have users.
So if I were marketing a vibe coded app, I wouldn't just make a video saying, Hey, guys, I built this app. I could download it because Who cares?

I'd actually make the building process part of marketing. I'd show the problems I'm trying to solve. I'd show myself building the app. I'd show the mistakes. I'd show the fast version. I'd show people actually using it. And most importantly, I'd make the content about the problem and not the fact that I used AI.
Because honestly, nobody cares that your vibe coded your app. They care about one thing, whether your app can make their life easier. That's the funny thing about web coding. AI has made building software ridiculously fast. But getting people to actually use what you built, that's the learning.

If you're vibe coding in an app right now, don't just ask yourself, What can I build? Ask yourself, who's actually going to care? Because building the app is only half the job. Getting people to CARE about it, that's the real challenge.

Yeah! Keep winning.

Software Architecture ideas every developer should know

Emmaculate Jane Akinyi Odhiambo — Wed, 02 Sep 2026 11:59:11 +0000

The payment went through but that's not the end, the account needs updating, a receipt needs to be sent, the user needs a notification and analytics need to record it.
One simple payment just triggered an entire chain of events. So how do we design a system where all these parts work together without creating a mess. Our application has different services running independently payment, notifications, analytics, we could make the payment service call each one directly.
Now everything starts depending on everything else, a better approach is event driven architecture. Instead of calling everyone the payment service can just announce, payment completed the other services listen for that event then react. The payment service doesn't need to know who is listening bit now what should actually be separated should payments be its own service, should refunds belong to payments, where does fraud detection fit, where do we draw the boundaries, that's where domain driven design comes in.
A Domain Driven Design software around the business and it rules instead of starting with database tables, we start with what the business actually does. For example payment, accounts, refunds, Fraud detection. notification, all these represent different business responsibilities and define where the boundaries should be.
Now we know what belongs where and how these parts communicate but inside each part we can still create a mess. Controllers talking directly to databases, business rules mixed with frameworks, payment providers spread throughout the code so how do we structure this code itself. That's why clean architecture come's in.
Clean Architecture structures the software such that the core business logic is separated from external technologies. The domain shouldn't care whether you're using Postgresql, Mongodb, Paysack or something else because technology changes every sing time but the core business logic should not have to change with it and now we connect the three ideas;
first, Domain Driven Design helps you understand the business and defines the boundaries.
second, Event Drive Architecture helps those parts communicate without tight coupling
Third, Clean Architecture structures the code inside those boundaries while protecting the business logic
But you don't need all three for every single application . A simple crud app probably doesn't need this architecture, this ideas become useful when your system and the complexity actually justify them. So we're not just adding more patterns make sure you are actually solving a problem.

HTTP

Emmaculate Jane Akinyi Odhiambo — Mon, 31 Aug 2026 11:31:37 +0000

Recently HTTP got an upgrade, if you are a developer you know what this means. After years of using the same HTTP methods like GET, POST, PUT and DELETE we finaly have a new standardized method called QUERRY

HTTP runs basically in the enter internet evrytime your phone talks to a server it uses GET to fetch something, POST to send something, PUT to update it, DELETE to remove it. That's been the toolkit for like two decades.

so why does this matter, let's sy you are building a search feature. If i just want one user i get request works perfectly, but what if i want all users in an engineering department with the role of admin sortaed alphabetically, filtered by date and split into pages. That request becomes too complex to fit nicely into a url. For years developers have worked aroundby using POST request, even though they are not actually creating anything and POST was never built for reading data it tells the internet "hey i'm changing something so you loose safe retries, cache, all the nice guarantees GET gives you.

So recently the IETF basically they grouped that writes the rule book for the internet, officially STANDARDIZED a brand new menthod called QUERY, you can send complex filters inside the body while still telling the server "hey i'm only reading the data, i'm not modifying anything." This means faster, safer more cacheable searches for basically evry app you use.

now before you rush to replace all your posts search and points don't support for querry is still rolling out. So many frameworks servers and API tools don't fully support it yet. Simple searches should still use GET and if users need to bookmark or share filterd results GET is still the better choice. this is one of those updates that shows the web is still evolving even after two decade

DOCKER

Emmaculate Jane Akinyi Odhiambo — Mon, 31 Aug 2026 07:34:22 +0000

There's always that moment when a fellow developer tells you pull the latest code and run it, you do exactly that and it doesn't work.

what version of node are you using ?
what database did you install? And suddenly we are now debugging you computer instead of the application. Let's see exactly how this happens

Imagine you are building a NodeJS application in your computer and on you computer you have NodeJS Version 22, Postgresql 16, redis and several other dependencies and this point everything works on your computer. Then your teammate downloads same project but they have NODEJS Version 20, a different Postgresql version 14 and they are missing on of your dependencies. Now suddenly the same code will behave differently. The problem isn't necessarily your code but the environment so how do we fix this?

Engineers asked why if we could package the application together with everything it needs to run, that is the application, it's dependencies, it's runtime, it's configurations and the run it anywhere, that idea has a name and it's called CONTAINERIZATION.

so what's a CONTAINER? this is basically an isolated environment that packages an application together with everything it needs to run. And now you are curious who actually builds and runs these containers. Let me introduce you to a tool known as DOCKER. Docker is one of the most popular tools for creating and running containers, but not this Docker doesn't just guess what to place inside your box, you have to actually define what goes inside the box and that definition is called a DOCKER FILe. This file tells the docker how to build the environment, start with NODE 22 create an application directory, install the dependencies, copy the application then tell it how to start. Once Docker follows those instructions it packs everything inside the box. That packed box before anyone opens it it's called AN IMAGE so practically its a read only template that's built from your docker file instructions.
so technically a container is a running instance of an image. So what does these actually solve?

Your teammate doesn't need to recreate your entire environment manually there's just need to open the same box you also deploy that same box to your server and now everyone is running the exact same packed environment but that doesn't mean every project needs to be dockerized. Docker shines when your app has dependencies or when your app has to run the same way across different machines or many developers

SO THE REAL SKILL IS NOT ACTUALLY KNOWING DOCKER BUT WHEN YOU ACTUALLY NEED IT

Backend Development in Flask

Emmaculate Jane Akinyi Odhiambo — Thu, 27 Aug 2026 07:36:49 +0000

Your app has two side, we have the frontend and backend. Frontend is what you see, the layout, the buttons etc. The backend is the engine, it's the brain of your website, it's the one that is storing the data, users, payments, authentications etc. Api is the messenger that is used to communicate between the two, basically when the frontend wants to request something from the backend it sends the api and then when backend wants to send back the response to the frontend it send s the API.
when talking about backend development you will hear people talk about Restful API's. So what does Rest means its the REPRESENTATION OF STATE TRANSFER. REST is not a framework or a library it's just a design style used to build predictable APIs, it practically gives the API structure. When using RESTFUL APIs you'll use this like get, put, post etc
Lastly we have JSON, what is JSON? This is basically the language format that is used to communicate between frontend and backend, so they practically communicate using JSON format eg { "name": "Emma", "age": 24 }. so what the backend does before it sends any data to the frontend it takes the python object in the code from your code or your database and then it takes that data and change it to JSON. Now the process of changing it to JSON format that that is called SERIALIZATION. When the backend now receives the data for example from the frontend and it wants to now handle it in terms of Python objects so it sends back data using the formart we are talking about the JSON format, python has to convert JSON object into python object. Now this conversion from JSON to python objects is called DESERIALIZATION

Backend Deployment

Emmaculate Jane Akinyi Odhiambo — Thu, 27 Aug 2026 07:01:04 +0000

The client says the site is down but it's working on my machine as developers we've all been there.the app works perfectly on the local host you test everything and it all works well, then you deploy to production that's where the genesis of our troubles starts and suddenly everything breaks. same code, same application so what changed actually a lot

first, environment variables on your laptops you already had your database password, your api keys, your secrete keys everything sited on your local environment. You deploy and one variable is missing or the database url is wrong or the api keys used belong to the test environment, your code is the same but your configuration is not

second, your production server my not even be running the same environment as your laptop develop on windows then you deploy on linux. you have on version of node, python or even PHP locally then in production it's different, it's something as simple as a filename can break a system. user service might work on a system while other user service might not

third, everything becomes so strict in production your fronted might be in one domain and your API in another cors matters because you might be using https on one request and your other request uses http. your login cookie is missing the correct same site secure or domain settings and suddenly users can not stay logged in.

Finally, real traffic local host, how many users are testing your app? One request comes in you up handles it and everything looks perfect but production might have hundreds of users hitting the same API at the very same time when your database runs out of connection, your memory fills up or it starts timing out two users try updating the same data and suddenly your app crashes, you never saw locally suddenly appears when someone says but it works on my machine, that may actually be the problem because production is not just you laptop on the internet, it has different configuration, system, security rules because of different browsers and real users hitting everything all at once. Everything may be the same but the environment around it is completely different.

Not everything needs an app

Emmaculate Jane Akinyi Odhiambo — Sat, 01 Aug 2026 10:32:32 +0000

If you are making me download a whole mobile app just for me to use it twice a year, then maybe you should just go back to user Experience classes. Correct me if I'm wrong but supposed to be downloading an app so that I can maybe pay a bill or even book an appointment or maybe just viewing the menu Seriously. Don't get me wrong native apps definitely have their space like banking, fitness training, tracking apps, gaming e.tc all that, things that heavily rely on your phone's hardware but this other app's please just make a website

Cache-Aside with REDIS

Emmaculate Jane Akinyi Odhiambo — Sat, 01 Aug 2026 10:13:59 +0000

Every time you open a amazon product or you refresh the same page, do you think that amazon sends a request to the database again. If millions of people are looking at the same product wouldn't that mean 1,000+ database queries and that's extremely expensive. So how do big companies avoid that? There's something called REDIS. REDIS is an in-memory cache, an in-memory cache simply means it stores data on RAM instead of disk cache cause RAM is much faster. REDIS can return data in just a few milliseconds but here's is the most interesting part REDIS doesn't just magically know what data to store and that's where a cache strategy known as a CACHE ASIDE comes in. A user request product 15 and the application ask REDISs, do you have product 15 REDIS says no. This is something known as CACHE MISS, simply means the requested data is not in the CACHE so the application goes to the database and finds product 15 it turns it to the application. Now here's the clever part before sending the product back to the user the application first stores a copy inside REDIS this is called POPULATING THE CACHE now REDIS remembers product 15 and finally the application sends back the product to the user a few seconds later another user requests product 15 again the application asks REDIS and this time REDIS replies product 15 is there. This is called CACHE HIT, it simply means that the requested data is in the cache so the application returns the product immediately and the database is never touched and that is why cache responses are so much faster.

Now let's imagine the product price changes from maybe 999 to 899 but remember the cache stills remember the former price. The cache contains stale data, Stale data simply means that the cache has outdated information. To fix this after updating the database the application deletes the product from REDIS and this is called CACHE INVALIDATION not because the data was bad but simply because it was incorrect data so now when another customer comes in and requests product 15, the application ask REDIS but remember the product was deleted so what will REDIS say, i don't have this product another cache miss so what does the application do, the application goes to the database because the product is unavailable here and then it goes to the database it finds the updated product 15 with the updated price so now it stores a copy in REDIS and then sends a response back to the user with the updated price. From that point on everybody receives the latest data directly from REDIS and remember REDIS is at the CACHE, CACHE aside is the cashing strategy. There are several caching strategies, CACHE aside is just one of the most common but it's not the only one.

Next time we'll explore different caching strategies and why CACHE aside is not used by some companies at all

Many believe AI can write code, fix bugs, build features, and eventually replace software engineers. The reality is different. AI is an incredible co-pilot, but it doesn't understand users, business goals, or the trade-offs behind building great software.

Emmaculate Jane Akinyi Odhiambo — Wed, 15 Jul 2026 19:11:38 +0000

AI Won't Replace Great Engineers—It Will Amplify Them

Emmaculate Jane Akinyi Odhiambo — Wed, 15 Jul 2026 19:07:05 +0000

I came across this image today, and it perfectly captures one of the biggest misconceptions about AI in software development.

People often think AI can:

Write code.
Fix bugs.
Build entire features.
Replace software engineers.

The reality is different.

AI is an incredible coding partner, but it doesn't understand your users, your business goals, or the trade-offs that make a product successful. Those are still engineering decisions.

As developers, we are responsible for:

Breaking complex problems into manageable pieces.
Designing scalable and maintainable solutions.
Understanding context and user needs.
Testing edge cases and ensuring quality.
Collaborating with teams and stakeholders.
Taking ownership when things go wrong.

AI helps us move faster by handling repetitive tasks, generating boilerplate code, explaining unfamiliar concepts, and speeding up debugging. But shipping valuable software still requires human judgment.

I've found that the best results come when engineers and AI work together—not when one tries to replace the other.

The future belongs to developers who know how to think, not just how to type code.

AI is a multiplier. Your engineering mindset is the advantage.

💬 Discussion: What's one way AI has made you a better developer without replacing your role?

DEVCommunity #SoftwareEngineering #AI #Programming #Developers #Coding #ProductDevelopment #Tech #MachineLearning #BuildInPublic