DEV Community: Moses Daniel Kwaknat

🧩 From REST to Events: Why Event-Driven Microservices Are the Upgrade You Didn’t Know You Needed

Moses Daniel Kwaknat — Tue, 01 Jul 2025 11:39:55 +0000

Building scalable systems today isn’t about throwing more servers at the problem, it’s about rethinking how your services talk to each other.

If you’ve ever been burned by tightly coupled REST calls in a microservice architecture, long chains of service-to-service calls, failed transactions halfway through, retry hell, you’re not alone.

Been there. Debugged that.
Let’s talk about the better way: event-driven architecture (EDA).

🧠 Microservices Were Supposed to Fix Everything… Right?
In theory, microservices let you:

Deploy independently
Scale granularly
Ship faster

But when your services are glued together with synchronous HTTP calls, you’re still in trouble:

Service A goes down → Service B fails too

Any latency → user feels it

You spend more time writing retries and fallbacks than business logic

That’s when I realized: the real unlock isn’t microservices alone, it’s event-driven microservices.

🔄 What Is Event-Driven Architecture?
In event-driven systems, services don’t call each other directly.
They emit events, and other services listen and respond.

participant OrderService
participant Kafka
participant PaymentService
participant InventoryService
participant ShippingService

OrderService->>Kafka: Publish "OrderPlaced"
Kafka->>InventoryService: "OrderPlaced"
Kafka->>PaymentService: "OrderPlaced"
InventoryService->>Kafka: "InventoryReserved"
PaymentService->>Kafka: "PaymentConfirmed"
Kafka->>ShippingService: "OrderReady"

This decoupling is game-changing.

🚀 Why It Works Better
✅ Loose coupling
Services don’t know about each other.
You can add or remove consumers anytime.

✅ Resilience
One service fails? Others still run.

✅ Scalability
Scale hot paths (e.g., payment, inventory) independently.

✅ Auditability
Events are logged — you get a trail of everything that happened.

✅ Asynchronous by default
Your users don’t wait while five services call each other like it’s a WhatsApp group chat.

🧰 Event Brokers: The Real MVPs
These tools make EDA possible:

Apache Kafka — High-throughput, persistent event log (my go-to)

RabbitMQ — Queue-based messaging with strong delivery guarantees

AWS SNS/SQS — Easy serverless messaging on the cloud

Others — NATS, Pulsar, Redis Streams

Pick one based on your throughput needs, latency tolerance, and operational skillset.

🛒 Real-World Flow: Order Processing
Let’s say you place an order. Here's how the services react:

OrderService emits OrderPlaced

InventoryService listens, reserves items

PaymentService listens, processes payment

ShippingService listens, ships once inventory + payment are confirmed

No service talks to another directly.
No coupling.
Just clean, reactive design.

⚠️ It’s Not All Rainbows
Yes, event-driven systems are powerful, but they’re not magic.

Here’s what to watch out for:

Eventual consistency: Not everything is instant.
Idempotency: Events can be duplicated. Handle it.
Schema evolution: Plan for versioning your events.
Debugging: Distributed tracing is a must.

🧠 Final Thoughts
If you want systems that are:

Scalable ✅

Resilient ✅

Loosely coupled ✅

Cloud-ready ✅

Then it’s time to look beyond REST.

Start small. Maybe just one async event.
Get a feel for it. Then go deeper.

Because in modern backend systems, the question isn't:

“Should I use microservices?”
It's:
“How are my services communicating?”

✍️ Written by Moses Daniel Kwaknat, backend engineer, API builder, and dev who’s finally making peace with distributed systems.

Let’s talk microservices, message brokers, or how to escape REST hell 👇

🐚 Bash: The Born Again Shell for Backend Developers

Moses Daniel Kwaknat — Mon, 16 Jun 2025 12:44:40 +0000

If you’ve been around backend engineering long enough, chances are you’ve had to wrestle with CLI commands, repeat setups, or manually spin up containers. But recently, I rediscovered an old friend: Bash, aka the Bourne Again Shell, or as I like to call it, the Born Again Shell 😅.

I had to write a helper script for a recent project, and the way everything was cleanly defined and automated made me fall in love with Bash all over again. This post is both a tribute to Bash and a practical guide to why and how backend engineers should embrace it.

🧑‍🔬 A Bit of History
Bash was created in 1989 by Brian Fox, a software engineer at the Free Software Foundation. It was intended as a free software replacement for the Bourne shell (sh), which was the standard shell on Unix systems.

And that’s where the clever naming comes in:

Bourne Again Shell = BASH — a pun on the original Bourne Shell by Stephen Bourne, not Brian Fox.

Why not name it after Fox? Well, turns out Brian Fox must have been a very modest guy 😅 (that's on a lighter note). The goal was to improve and replace the Bourne Shell, not to rebrand it entirely and that was why it was named after Bourne. Bash aimed to preserve compatibility while adding powerful features.

💡 Why Backend Engineers Should Care About Bash
While tools like Docker, Kubernetes, and cloud dashboards have taken over much of our workflows, Bash is still one of the most powerful developer productivity tools. Here's why:

🛠 Automation: Set up containers, build projects, and run migrations, all with one script.

🧼 Consistency: No more "it works on my machine" when every dev runs the same .sh file.

🚀 Speed: Running a full dev environment becomes a single command away.

📦 The Project That Got Me Hooked Again
Here’s a trimmed version of a helper script I wrote to bootstrap, manage, and test a microservices backend project using Docker Compose, PNPM, and TypeORM migrations:

bash
Edit
!/bin/bash

dev.sh — Development helper script

GREEN='\033[0;32m'
YELLOW='\033[1;33m'
NC='\033[0m' # No Color

case "$1" in
up)
echo -e "${GREEN}Starting all containers...${NC}"
docker-compose up -d
;;
down)
echo -e "${GREEN}Stopping all containers...${NC}"
docker-compose down
;;
logs)
docker-compose logs -f app
;;
migration:run)
docker-compose exec app pnpm run migration:run
;;
test:e2e)
docker-compose exec app pnpm run test:e2e
;;
bash)
docker-compose exec app /bin/sh
;;
*)
echo -e "${YELLOW}Available commands: up, down, logs, migration:run, test:e2e, bash${NC}"
;;
esac

I used this script to build, test, and iterate faster. No more jumping between README instructions or forgetting flags!

🔧 Getting Started with Bash for Your Project

Create a dev.sh file at the root of your project:
touch dev.sh
chmod +x dev.sh
Add your commands and color formatting
You can define helpful colors, usage descriptions, and subcommands like up, down, migrations, etc.
Use chmod +x dev.sh
Make it executable so you can run it like:

./dev.sh up
./dev.sh logs

✨ Final Thoughts
Bash might not have the flashiness of modern CLIs or GUIs, but it offers a superpower that many backend engineers overlook: repeatable and scalable developer experience.

For me, Bash is no longer just the default shell, it's a productivity layer I now plan to use in every future project.

So next time you're setting up a backend repo, think of Bash… or should I say, the Born Again Shell 😅.

💬 Over to You
Do you use Bash in your backend workflows? What tricks or helper scripts have you written?

Let’s share some CLI love in the comments 👇

# AI vs ML vs DL: What’s the Difference and When Should You Use Each?

Moses Daniel Kwaknat — Wed, 04 Jun 2025 15:12:34 +0000

As someone diving deep into AI, machine learning, and backend systems, I often get asked:

"What's the difference between AI, ML, and deep learning?"
"Which one should I use in my project?"

If you're building real-world systems, especially in fintech, edtech, or African startups, knowing the difference isn't just academic. It’s practical.

Let’s break it down 👇

🤖 Artificial Intelligence (AI)

AI is the broadest term.

It refers to any technique that enables machines to mimic human intelligence.

Examples:

Rule-based chatbots
Game bots that mimic human strategy
Smart assistants like Siri or Alexa

AI ≠ just learning from data. It includes hardcoded logic and decision trees too.

Use AI when:

You need a system to simulate reasoning or human-like decisions
The problem doesn't involve tons of raw data

📈 Machine Learning (ML)

ML is a subset of AI.

It involves algorithms that learn from data instead of being explicitly programmed.

Examples:

Spam filters that learn patterns in emails
Recommendation systems like Netflix or TikTok
Fraud detection based on user behavior

ML models find patterns, learn from past outcomes, and make predictions.

Use ML when:

You have data and want to make predictions
You want to build adaptive systems (e.g., fraud detection, dynamic pricing)

🧠 Deep Learning (DL)

Deep Learning is a subset of ML.

It uses neural networks, inspired by the human brain, to learn complex patterns.

Examples:

Facial recognition
Voice assistants that transcribe speech
Generative models (like ChatGPT or DALL·E)

DL models usually require:

Large datasets
High computing power (GPUs, TPUs)

Use DL when:

You have huge amounts of unstructured data (images, text, audio)
Traditional ML models aren’t performing well

💡 Which One Should You Use?

Use Case	Technique
Predict customer churn	ML
Classify documents	ML / DL
Voice command system	DL
Loan risk scoring	ML
Rule-based loan approval	AI (non-ML)
Smart assistant	AI + ML + DL

🧠 Final Thoughts

AI is the big picture
ML is data-driven intelligence
DL is the powerhouse for unstructured data

You don’t need DL for everything. Often, classical ML (like decision trees or logistic regression) works just fine.

💬 I’m currently working on applying ML in real-world African problems — from fake news detection to smart energy systems. Want to collaborate or discuss use cases? Drop a comment!

Writing Modular and Scalable Services with NestJS

Moses Daniel Kwaknat — Mon, 02 Jun 2025 14:49:57 +0000

Summary: A deep dive into how I structure backend services with NestJS for scalability, readability, and real-world performance in fintech and production systems.

As a backend engineer working in production systems, I’ve found that NestJS provides a powerful structure out of the box, but it’s still up to you to organize your services in a clean, scalable way.

In this post, I’ll walk you through how I build modular services with NestJS that are:

Easy to maintain ✅
Testable ✅
Scalable across teams and features ✅

1. Use Feature-Based Folder Structure

Instead of separating code by type (controllers, services, models), I prefer feature-based organization:

/src
/payments
payment.controller.ts
payment.service.ts
payment.module.ts
/users
user.controller.ts
user.service.ts
user.module.ts

This structure makes it easier to scale horizontally and keep related files close together.

2. Split Business Logic Into Services (and Sub-Services)

Keep your controllers thin.

Keep your services focused.

If a service is doing too much, break it down further.

Example:

@Injectable()
export class PaymentService {
  constructor(
    private readonly transactionService: TransactionService,
    private readonly walletService: WalletService,
  ) {}

  async processPayment(...) {
    await this.walletService.debit(...);
    await this.transactionService.record(...);
  }
}

3. Use Modules to Enforce Boundaries

NestJS modules help you control visibility and prevent accidental imports from unrelated parts of the app.

Export only what you want others to access:

@Module({
  providers: [UserService],
  exports: [UserService], // exposed to other modules
})
export class UserModule {}

4. Set Up Proper Dependency Injection (DI)

One of Nest’s biggest strengths is its DI system. You should:

Use constructor injection (not manual instantiation)

Keep dependencies explicit

Extract shared logic into utils or libs

5. Create a Shared Module for Common Logic

If multiple modules reuse the same service, guard, or pipe, move it into a SharedModule.

/shared
logging.interceptor.ts
current-user.decorator.ts
pagination.pipe.ts

Conclusion

NestJS gives you the tools, but clean architecture is still your job.
By sticking to modular structure, separating concerns, and using the DI system right, you can scale your codebase and your team with confidence.

Have you used NestJS in production? How do you structure your services?

Let’s swap notes 👇

nestjs #backend #nodejs #scalablearchitecture #typescript #webdev #softwareengineering #modulararchitecture