DEV Community: Emmaculate Jane Akinyi Odhiambo

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

Being a Full-stack Developer

Emmaculate Jane Akinyi Odhiambo — Fri, 05 Jun 2026 11:55:45 +0000

Let's be honest about what "Full-Stack" actually requires. 🧵

That fancy title covers FOUR completely different disciplines:

1️⃣ FrontEnd — HTML, CSS, JS + React/Vue/Angular
2️⃣ BackEnd — Node, Python, PHP + API design + Redis
3️⃣ Database — SQL (PostgreSQL/MySQL) + NoSQL + Message queues
4️⃣ DevOps — Docker, Kubernetes, AWS + CI/CD pipelines

That's not one skill. That's four careers in one job description.

So here's my advice:

→ Don't panic looking at the full list
→ Don't skip fundamentals to chase frameworks
→ Don't call yourself full-stack until you've shipped something real at each layer

Start with Frontend (HTML → CSS → JS → one framework).
Then Backend (one language, REST APIs, one database).
Then learn DevOps when you have something worth deploying.

The roadmap is real. The shortcut is not.

Save this. Come back to it in 6 months. You'll be surprised how far you've moved.

FullStackDeveloper #TechCareer #LearnToCode #BackEnd #FrontEnd #Database #DevOps

Who is a full-Stack Developer

Emmaculate Jane Akinyi Odhiambo — Fri, 05 Jun 2026 11:50:10 +0000

🚀 Everyone wants to be a "Full-Stack Developer" — but what does that actually mean?

Here's the honest breakdown:

💻 FrontEnd — What users SEE
→ Start with HTML, CSS & JavaScript (the holy trinity)
→ Then pick a framework: React, Vue, or Angular
→ Polish it with Material UI or Bootstrap

⚙️ BackEnd — What makes things WORK
→ Choose your language: Node.js, Python, PHP, or Ruby
→ Learn how APIs and server logic connect everything
→ Redis for caching — because speed matters

🗄️ DataBase — Where data LIVES
→ SQL first (MySQL, PostgreSQL) — this is non-negotiable
→ Then explore NoSQL: MongoDB, Cassandra, Elasticsearch
→ Message queues (Kafka, RabbitMQ) for scalable systems

☁️ DevOps — How code gets DEPLOYED
→ Learn Docker before Kubernetes
→ Pick a cloud: AWS, Azure, or GCP
→ Automate with Ansible, Chef, or Jenkins

The biggest mistake most developers make?
Trying to learn ALL of this at once.

Here's what actually works:
✅ Master one layer completely
✅ Build a real project with it
✅ Then move to the next layer

You don't need every tool on this list.
You need DEPTH in a few, and awareness of the rest.

That's what separates a real full-stack engineer from someone who just watched tutorials.

Which layer are you currently working on? Drop it below 👇

FullStack #WebDevelopment #Programming #SoftwareEngineering #DevOps #CareerGro

Productivity Booster

Emmaculate Jane Akinyi Odhiambo — Tue, 02 Jun 2026 08:49:38 +0000

Here are 5 simple things I started doing that completely changed my productivity:

The 20-Minute Rule for Being Stuck
If I cannot solve a bug or configuration error within 20 minutes, I stop guessing. I force myself to look at the official documentation, search the DEV Community, or ask a colleague. This saves hours of aimless troubleshooting.
Writing Down the Goal Before Coding
Before typing a single line of code, I write down exactly what I am trying to build in plain text. Having a clear roadmap prevents feature creep and keeps my pull requests small and focused.
Turning Off Non-Urgent Notifications
Context switching is a productivity killer. I close my email client and mute general chat channels for two blocks of 90 minutes each day. The uninterrupted focus allows me to enter a state of deep flow.
Reading Code, Not Just Writing It
Every week, I spend 30 minutes reading open-source repositories or pulling up code written by senior engineers on my team. Seeing how others structure their solutions expands my perspective.
Committing Small, Committing Often
Instead of waiting until the end of the day to make one massive commit, I commit every time a small sub-task works. It serves as a safety net and makes my Git history clean and easy to follow.