DEV Community: Victor Ng'ang'a

Monoliths, Modular Monoliths, and Microservices: A Developer's Reflection

Victor Ng'ang'a — Tue, 01 Jul 2025 07:20:51 +0000

Monoliths, Modular Monoliths, and Microservices: A Developer's Reflection

After working on different projects: some small, others growing fast. I’ve been forced to ask myself:

“What’s the right architecture for where I am?”

Along that journey, I’ve had the chance to explore all three key approaches: Monoliths, Modular Monoliths, and Microservices, especially in a Dockerized environment.

Here’s what I’ve come to understand from actually building with them:

🧱 Monoliths –> Start Simple

A monolith is a single codebase where all your logic/APIs, services, UI; lives and is deployed together.

For most early-stage apps, especially solo-built ones:

✅ Easy to start, build, test, and deploy
✅ Less overhead
🚫 Doesn’t scale well with growing complexity

It works great for early MVPs where the focus is speed over long-term structure.

🧩 Modular Monolith –> The Sweet Spot for Many

A modular monolith keeps everything in one repo and process but divides functionality into clear, separate modules / apps.

Think: purchases, sales, payments as independent Django apps within one project.

Why it works well for me:

Modules are independently testable
If payments fail, sales still work
It is easier to onboard new devs into a single repo
And when scaling comes into the picture, extracting a module into a microservice is painless

This structure hit a sweet spot: Clean enough to grow, simple enough to deploy.

🔗 Microservices –> Powerful, but Heavy

Later, I interacted with projects built entirely as microservices:

Each module had its own repo
Each service had its own runtime
Services talked over REST or messaging systems

This enables:

🚀 Independent scaling
👥 Team autonomy
🔄 Service-specific deployments

But comes at a cost:

You now manage 5–10 services, not one
Networking, monitoring, and syncing data get tricky
CI/CD needs to be rock solid

If you’re a small team, microservices might feel like overkill until you really need them.

🐳 Docker’s Role in All This

Docker is a huge enabler across all three approaches.

Monoliths → 1 image, 1 container
Modular Monolith → 1 container, multiple logical modules
Microservices → Multiple containers, each service in its own environment

As I learned more, I discovered tools like:

docker-compose : to spin up dev environments with multiple services
Kubernetes : to manage containerized apps in production

For monoliths and modular monoliths, Docker makes deployment simple.

For microservices, Docker makes it possible at all.

🎯 Conclusion: My Advice?

✅ Start with a monolith when it’s just you or your MVP.
🧩 Modular monolith when you expect growth, it’s the most forgiving and flexible structure.
🚀 Microservices when your scale and team size demand it, but only when you’re ready for the operational cost.

Let me know what architecture your project is using and why you chose it.

Would love to hear how others are approaching system design in real-world situations.

-vn-vision

Catching bugs before they bite: Django Testing

Victor Ng'ang'a — Tue, 10 Jun 2025 18:57:47 +0000

Week 5: Testing Everything—Unit, Integration, Functional & Beyond

TL;DR

I wrote and ran unit, integration, functional, smoke, and regression tests for Vimist’s services and endpoints—uncovered atomicity and signal bugs that only appeared on a live server.

1. Unit Tests for Core Services

What I tested:
- process_sale
- process_purchase
- Credit account adjustments
Goal: Verify business logic in isolation before touching the database or HTTP layer.

2. Integration Tests Across Services

Focus: Ensure related functions play nicely together.
Scenarios:
- Sale → inventory decrement
- Purchase → inventory increment
- Credit sale limits & repayments
- Mixed payment methods: Cash, M-Pesa, Credit

3. Functional Flow Verification

End-to-end checks:
- User signup + alert notification
- Making purchases & payments
- Low-stock and overdue payment alerts

4. Manual “Live” Testing Catches What Code Can’t

How: Hit the real API server with Postman/cURL.
Findings:
- Sales weren’t fully atomic—errors raised but records still saved.
- Duplicate credit entries when serializers and signals both processed transactions.

Lesson: Unit & integration tests are great—but manual/smoke tests on the live server are invaluable for catching signal- and transaction-related bugs.

Final Thoughts

Testing isn’t just a checkbox, it’s your fastest path to confidence and fewer late-night fire drills.

Next up: automating CI/CD pipelines to run these tests on every push.

See you in Week 6!

-vn-vision

Serializers, ViewSets, and Security — Making the System Talk

Victor Ng'ang'a — Thu, 05 Jun 2025 08:30:05 +0000

Week 4: Serializers, ViewSets, and Security — Making Vimist Talk

This week was about getting Vimist to communicate — from models to APIs to responses.

🧭 Vimist API Request Flow

Here's how a typical request travels through the Vimist system:

1️⃣ Client
→ Browser or mobile app sends a request

2️⃣ HTTP Request
→ Type: GET, POST, PUT, or DELETE

3️⃣ urls.py
→ Matches request to a route (e.g. /sales/)

4️⃣ views.py
→ Entry point for logic (SaleViewSet)
→ Calls serializer and handles permissions

5️⃣ serializers.py
→ Validates and transforms data
→ Triggers service logic like process_sale()

6️⃣ models.py
→ Interacts with the database
→ Uses signals for consistency and atomicity

7️⃣ Response
→ Sends back a JSON or XML response to the client

💡 Each part has a role. Want more? Check the full breakdown below.

🔄 Serialization Deep Dive

I learned how to transform model instances and querysets into JSON/XML and back.

✅ ModelSerializers: quick and DRY, great for prototyping.
🛠 Manual Serializers: more verbose, but perfect when I needed full control.

📡 Views and APIs

Once serialization was working, I moved on to views.

Used ModelViewSets for standard CRUD.
Switched to generics where I needed custom logic.

The choice often boiled down to clarity vs control.

🔐 Securing the Endpoints

I implemented permission_classes to make sure:

Only authenticated users could interact with the system.
Each view was tied to the user’s role (RBAC).

🧠 Delegating to Services

To keep views thin, I offloaded business logic to services called by serializers:

process_sale
process_purchase
credit_transactions
credit_accounts

It made testing easier and the codebase cleaner.

⚖️ Signals & Consistency

Using Django signals, I ensured that:

All transactions are atomic
Database state stays consistent even if something fails mid-way, no half-done work

🧭 Vimist API Flow (Simplified)

Client
↓
HTTP Request (GET/POST/PUT/DELETE)
↓
urls.py (Route matching)
↓
views.py (e.g. SaleViewSet)
↓
serializers.py (Validation & transformation)
↓
models.py (Database operations)
↓
Response (JSON/XML to client)

🧵 Wrapping It Up

Week 4 was about making the backend talk and listen.

I’m slowly tying the pieces together — from design to function to security.

Each layer now has a purpose, and the system is becoming more predictable and stable.

Week 5… let’s ship more.

- vn-vision

System Revamp: Stepping Into System Design

Victor Ng'ang'a — Mon, 26 May 2025 15:39:02 +0000

Week 3: A Shift in Perspective

Quick Snapshot

Learned from Gaurav Sen's system design series

Started redesigning my Vimist POS + Inventory system

Focus: consistency, transactional integrity, scalability

Tech: Django, MySQL, Docker, REST APIs, RBAC

LLD in progress, HLD shaping up

Two weeks ago, I started blogging. I had no clear direction — just a deep desire to share. That led to my first post: I Almost Didn’t Write This.

By week two, I had dived into Docker and system design, writing about scaling, security, and why DevSecOps matters.

This Week: System Design Hit Me Hard

After bingeing Gaurav Sen's system design breakdowns (Tinder, WhatsApp, Instagram), I saw things differently.

It made me look at my own project — Vimist, a POS and Inventory app — and realize:

It could be better.

So I paused building... and started redesigning.

Core Requirements I Mapped Out

Inventory management
Purchases (what, where, who, how paid)
Sales (to whom, by whom, payment method)
Credit tracking w/ limits & repayments
Notifications: low stock, overdue payments
Payment types: cash, mobile money, credit
Business branding: themes, logos, company details

Tradeoffs and Decisions

Consistency is a must — money’s involved.

That left me debating between:

Availability
Partition tolerance

Still undecided. Any thoughts?
Share down in the comments.

Stack I Chose

🧱 REST APIs for simplicity
🐬 MySQL for strong ACID guarantees
🐳 Docker to scale across systems
🔐 RBAC via Django (middleware + signals)

Currently working on the LLD (schema, services). HLD coming together too. -- coming soon

Closing Thoughts

This journey isn’t fast — but it’s moving.

And that’s what matters.

Sometimes, slow forward beats a backward step.

If you’re building anything similar or have thoughts on consistency vs Partition Tolerance, hit me up in the comments.

See you in Week 4.

vn-vision

DevSecOps & Scale: Docker, Security, and System Design

Victor Ng'ang'a — Mon, 19 May 2025 16:24:38 +0000

This week I dove into the full spectrum of DevSecOps & System Design—from building and deploying containers to hardening them, all the way through the architectural patterns that make systems scale. Here’s what I learned, why it matters, and how you can apply it in your journey too.

🐳 Docker Deep Dive

Why Docker?

Portability: “It works on my machine” becomes universal
Isolation: Dependencies and services can’t interfere
Reproducibility: CI/CD pipelines run identical builds
Resource Efficiency: Lightweight compared to full VMs

Hands‑On Highlights

Wrote my first Dockerfile and built custom images
Orchestrated multi‐container setups with docker-compose.yml
Deployed images locally and inspected running containers
Learned best practices: minimal base images, multi‐stage builds

Tip: Start with an official Python/Django image, then strip out dev tools in a second stage to keep your final image lean.

🛡️ Container Security

Building on Docker, I explored how to harden a container:

Scanning images for known vulnerabilities (e.g. docker scan)
Running containers as non‑root users
Restricting filesystem permissions (read‑only mounts)
Using Docker’s built‑in secrets management

I also mapped these practices to Django’s security features:

OWASP Top 10 awareness (SQLi, XSS, CSRF)
Enabling SECURE_SSL_REDIRECT, X_FRAME_OPTIONS, etc.
Writing and testing signals that log suspicious behavior

Resource: Check out Django’s security checklist.

🔁 Cybersecurity Mindset

Security is more than config flags—it’s a way of thinking. I practiced:

Threat modeling each feature before building it
Crafting unit tests for signal‑based audits in Vimist
Inspecting Docker logs for anomalous behavior
Studying OWASP injection and auth attacks

Exercise: For every new endpoint, ask “What happens if someone sends malicious input?” and write a test case to prove your defenses.

🚀 System Design Foundations

To see how all these pieces fit, I explored key architectural patterns:

Concept	Why It Matters
Scalability	Ensure the app can handle growing load
Load Balancing	Distribute requests evenly to prevent bottlenecks
Consistent Hashing	Minimize data reshuffling when adding/removing nodes
Message Queues	Decouple services and absorb traffic spikes
Sharding	Split data across databases to boost performance

Tip: Start simple—spin up two web containers behind Nginx, then add a message queue for background jobs.

💡 Daily LeetCode

I kept my problem‑solving sharp with a daily LeetCode challenge. Even 30 minutes each morning reinforces algorithmic patterns and prepares me for technical interviews.

🔭 Next Steps

Continuous Learning: continue growing my skills, let's see how it goes.

Key Takeaway:

Learning at the intersection of DevOps, security, and architecture transforms you from a coder into a systems thinker. Every container you build, every threat you model, and every design pattern you master compounds into real‑world resilience and scale.

Thanks for reading Post #2 of :Code.Secure.Scale.
If you found this helpful, let’s connect and learn together!

– vn-vision

I Almost Didn’t Write This — But Here’s Why I Did Anyway

Victor Ng'ang'a — Mon, 12 May 2025 14:24:43 +0000

This time is set aside for me to blog, improve my social media presence, and hopefully make something impactful.
Well, here I am, chatting with my GPT model. Hey there, ChatGPT.

I didn’t want to just write about anything out of the blue. I want what I post to mean something — to me, and to whoever reads it.

The First Idea: Pawned Boxes
Initially, I thought I’d write about all the different machines I’ve pawned — give a walkthrough, share some alternatives, and reflect on how I got there. The stories behind each box are personal. But I haven’t written that post yet. I haven’t even pawned all of them. So I shelved that idea for now.

The Second Idea: A Day in My Life as a Developer
Then I figured, why not take people through my day as a developer? But again, I paused. I wondered if that would really help anyone. Every dev has their routine — what would make mine worth reading?

That’s when something clicked.

Why Not Both?
What if I don’t have to choose?
What if I talk about the boxes I’ve pawned and the life I live behind the keyboard that led to those moments? What if I tell real stories, then tie them back to the developer experience — both the highs and the struggles?

I could share the tech problems I face in React, Redux, TypeScript, Django, Node.js, REST APIs, Docker containers — all of it. But I want to do it differently. I want my content to mean something. Not just tutorials, but context. Real-life situations where these tools either saved me or failed me.

The Question That Stays With Me: How Do I Stand Out?
I’m still figuring that out.
Maybe it’s my storytelling. Maybe it’s the fact that I’m living it — and not pretending to have all the answers. Maybe it’s the willingness to be honest, even when I feel unsure.

Instead of keeping this thought process to myself, I decided to chat with ChatGPT.
It may not qualify as a blog post in the traditional sense — but it’s better than waiting for the “perfect idea.”

And hey, I showed up.
I didn’t let this pass me by.
I didn’t postpone it till I had something “worthy.”
I just did it.

And that’s where I’ll start.

Thanks for reading.
This isn’t the peak. It’s the beginning.
Let’s see where this goes.

vn-vision.