DEV Community: Mehdi Hassan Jony

Stop Wasting Days on Dev Setup: How We Automated Our Microservices Environment for Every Developer

Mehdi Hassan Jony — Tue, 22 Sep 2026 08:38:16 +0000

How we reduced new developer onboarding from 3 days to 15 minutes and eliminated configuration drift across 12 microservices.

The Problem That Made Us Snap
Picture this: A new senior developer joins your team. They’re excited, ready to ship code on day one. Then reality hits.
Day 1: They spend 6 hours installing Node, Docker, configuring ESLint to match the team’s style, figuring out which environment variables go where, and asking Slack questions like, “Which version of NestJS are we on again?”
Day 2: They finally get user-service running, but auth-service throws a CORS error because their local config is slightly different from everyone else’s. They spend the afternoon comparing .env files with a teammate.
Day 3: They submit their first PR. The CI pipeline fails because their local Prettier config formats code differently from the shared config that was updated last month — but nobody told them.
Sound familiar?
We had 12 microservices, a team that was growing fast, and a configuration mess that was eating our productivity alive. Every service had slightly different ESLint rules, Docker setups, folder structures, and VS Code settings. Senior developers were spending hours every week answering setup questions instead of building features.
So we built a system that fixed all of it. Here’s exactly how.

The Solution: One Repo to Rule Them All

We created a central configuration repository called dev-environment-config that acts as the single source of truth for every development environment across our entire microservices ecosystem.
The idea is simple:

One repository controls the setup, structure, linting, Docker config, VS Code settings, and shared code for every service. When a senior developer updates it, every developer’s machine automatically syncs the next morning.

The Architecture at a Glance

dev-environment-config (Central Repo)
├── templates/          → Project scaffolding (NestJS, React)
├── shared/             → ESLint, Prettier, Git configs
├── vscode/             → Extensions & settings
├── docker/             → Base Docker configs
├── scripts/            → Automation (setup, sync, update)
├── common-lib/         → Shared NPM package
└── manifest.json       → Version tracking

         │  syncs to
         ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ user-svc │ │ auth-svc │ │ pay-svc  │  ... 12 services
│ .eslint  │ │ .eslint  │ │ .eslint  │
│ .vscode  │ │ .vscode  │ │ .vscode  │
│ Docker   │ │ Docker   │ │ Docker   │
└──────────┘ └──────────┘ └──────────┘

Implementation: Step by Step

Step 1: The Central Config Repository

We created a new repository with this structure:

dev-environment-config/
├── templates/
│   ├── nestjs-service/    # Complete NestJS starter
│   └── reactjs-service/   # Complete React starter
├── shared/
│   ├── .eslintrc.js
│   ├── .prettierrc
│   ├── .editorconfig
│   ├── .gitignore
│   └── commitlint.config.js
├── vscode/
│   ├── extensions.json
│   ├── settings.json
│   └── launch.json
├── scripts/
│   ├── setup-new-developer.sh
│   ├── sync-config.sh
│   ├── auto-update.sh
│   └── create-new-service.sh
├── common-lib/            # Shared NPM package
└── manifest.json          # Version tracker

The manifest.json is the heartbeat of the system:

{
  "version": "1.2.0",
  "lastUpdated": "2024-01-15T10:00:00Z",
  "updatedBy": "senior-dev",
  "configs": {
    "eslint": "3.2.0",
    "prettier": "2.1.0",
    "docker": "1.5.0"
  },
  "services": [
    "user-service",
    "auth-service",
    "payment-service"
  ]
}

Every time a config changes, we bump the version. This is how the auto-update system knows something changed.

Step 2: The One-Command Onboarding Script

This was the game-changer. We wrote a bash script that a new developer runs once, and their entire environment is ready.

The new developer’s experience:

Install VS Code ✅
Run one command:

curl -sSL https://raw.githubusercontent.com/company/dev-environment-config/main/scripts/setup-new-developer.sh | bash

Wait ~10 minutes. Done.

What the script does under the hood:

#!/bin/bash
set -e

WORKSPACE_DIR="$HOME/company-workspace"
CONFIG_REPO="https://github.com/company/dev-environment-config.git"

echo "🚀 Setting up your development environment..."

# 1. Check & install prerequisites
check_and_install "git" "Git"
check_and_install "node" "Node.js" "nvm install 20"
check_and_install "docker" "Docker"

# 2. Create workspace & clone everything
mkdir -p "$WORKSPACE_DIR" && cd "$WORKSPACE_DIR"
git clone "$CONFIG_REPO"

# 3. Clone all service repos from manifest
SERVICES=$(cat dev-environment-config/manifest.json | \
  python3 -c "import sys,json; \
  [print(s) for s in json.load(sys.stdin)['services']]")

for service in $SERVICES; do
  git clone "https://github.com/company/${service}.git"
done

# 4. Install VS Code extensions
EXTENSIONS=$(cat dev-environment-config/vscode/extensions.json | \
  python3 -c "import sys,json; \
  [print(e) for e in json.load(sys.stdin)['recommendations']]")

for ext in $EXTENSIONS; do
  code --install-extension "$ext" --force
done

# 5. Sync shared configs to all services
bash dev-environment-config/scripts/sync-config.sh

# 6. Install dependencies everywhere
for service in $SERVICES; do
  cd "$service" && npm install && cp .env.example .env && cd ..
done

# 7. Set up daily auto-update cron (8 AM weekdays)
CRON="0 8 * * 1-5 cd $WORKSPACE_DIR && \
  bash dev-environment-config/scripts/auto-update.sh"
(crontab -l 2>/dev/null; echo "$CRON") | crontab -

echo "✅ Setup complete! Open VS Code: code $WORKSPACE_DIR"

That’s it. The developer opens VS Code, and everything is configured — extensions, linting, formatting, Docker, environment variables, the works.

Step 3: The Config Sync Script

This script copies the shared configs from the central repo into every service:

#!/bin/bash
# sync-config.sh

CONFIG_ROOT="$(dirname "$SCRIPT_DIR")"
WORKSPACE_DIR="$(dirname "$CONFIG_ROOT")"

for service in $SERVICES; do
  SERVICE_DIR="$WORKSPACE_DIR/$service"

  # Copy shared configs
  cp -f "$CONFIG_ROOT/shared/.eslintrc.js" "$SERVICE_DIR/"
  cp -f "$CONFIG_ROOT/shared/.prettierrc" "$SERVICE_DIR/"
  cp -f "$CONFIG_ROOT/shared/.editorconfig" "$SERVICE_DIR/"
  cp -f "$CONFIG_ROOT/shared/.gitignore" "$SERVICE_DIR/"

  # Copy VS Code settings
  mkdir -p "$SERVICE_DIR/.vscode"
  cp -f "$CONFIG_ROOT/vscode/settings.json" "$SERVICE_DIR/.vscode/"
  cp -f "$CONFIG_ROOT/vscode/extensions.json" "$SERVICE_DIR/.vscode/"

  echo "✅ $service synced"
done

Step 4: The Daily Auto-Update (The Magic)

This is the part that keeps everything in sync without anyone thinking about it.
Every morning at 8 AM (weekdays), a cron job runs auto-update.sh on every developer’s machine:

#!/bin/bash
# auto-update.sh — Runs daily at 8 AM

cd "$CONFIG_ROOT"

# 1. Check for config updates
OLD_VERSION=$(cat manifest.json | jq -r '.version')
git pull origin main
NEW_VERSION=$(cat manifest.json | jq -r '.version')

if [ "$OLD_VERSION" != "$NEW_VERSION" ]; then
  echo "🆕 Config updated: $OLD_VERSION → $NEW_VERSION"
  bash "$SCRIPT_DIR/sync-config.sh"
fi

# 2. Pull latest code for all services
for service in $SERVICES; do
  cd "$WORKSPACE_DIR/$service"

  # Stash local changes safely
  git stash push -m "auto-update-$(date +%Y%m%d)" 2>/dev/null

  # Pull latest
  git pull origin $(git branch --show-current) --rebase

  # Update dependencies if package.json changed
  if git diff HEAD~1 --name-only | grep -q "package.json"; then
    npm install
  fi

  # Update shared library
  npm update @company/common-lib
done

# 3. Notify the developer
notify-send "Dev Environment" "✅ Updated to config v$NEW_VERSION"

The flow:

Senior Dev pushes config change
         │
         ▼
   GitHub Actions
         │
    ┌────┴────┐
    │ Slack   │ Notify team
    │ Publish │ common-lib to NPM
    └────┬────┘
         │
    Next 8 AM
         │
         ▼
  Every developer's cron runs
         │
    ┌────┴────────────────┐
    │ Pull config repo    │
    │ Sync shared configs │
    │ Pull service repos  │
    │ Update dependencies │
    │ Desktop notification│
    └─────────────────────┘

Step 5: The Shared Common Library

Instead of copying and pasting guards, interceptors, and DTOs across 12 services, we created @company/common-lib — a private NPM package:

// In any service, just import and use:
import {
  AuthGuard,
  RolesGuard,
  ResponseInterceptor,
  LoggingInterceptor,
  HttpExceptionFilter,
  PaginationDto,
  McpService,        // Qwen MCP integration
} from '@company/common-lib';

@Controller('users')
@UseGuards(AuthGuard, RolesGuard)
@UseInterceptors(ResponseInterceptor)
@UseFilters(HttpExceptionFilter)
export class UserController {
  constructor(private mcpService: McpService) {}

  @Get()
  findAll(@Query() pagination: PaginationDto) {
    return this.userService.findAll(pagination);
  }

  @Post('analyze')
  async analyze(@Body() dto: AnalyzeDto) {
    return this.mcpService.callTool('text-analysis', {
      text: dto.text,
    });
  }
}

When we update the common library (add a new guard, fix a bug in the exception filter), the auto-update system bumps the version in every service automatically.

Step 6: Service Scaffolding

Creating a new microservice used to take a day of copy-pasting and tweaking. Now it takes 30 seconds:

bash scripts/create-new-service.sh

# Prompts:
# Service name: order-service
# Description: Handles order processing
# Port: 3002
# Type: nestjs

# ✅ Done! Complete service with:
# - src/common/ (filters, guards, interceptors, DTOs)
# - Docker setup (Dockerfile + docker-compose)
# - VS Code settings
# - ESLint + Prettier
# - Health check endpoint
# - Swagger docs
# - MCP integration
# - Auto-update scripts

The Benefits (With Real Numbers)
1. Onboarding: 3 Days → 15 Minutes

Before: Manual setup following a 40-step Confluence page.
After: One curlcommand.
Before: 3 days to first productive commit.
After: 15 minutes to running all services.
Before: "Hey, can you help me with my env vars?" (daily Slack noise).
After: Zero setup questions.

2. Configuration Drift: Eliminated
Before, every service slowly diverged. user-service had ESLint v8, auth-service had v7. Prettier configs had subtle differences. Docker setups were copy-pasted and never updated. Now, every service has identical configs, and they stay identical because the sync script overwrites them daily.

3. Senior Developer Time: Saved ~5 Hours/Week
Senior devs were spending roughly an hour a day helping juniors with setup issues, reviewing PRs that failed CI due to formatting, and manually updating configs across services. That time is now spent building features.

4. Consistent Code Quality
Every developer has:

The same ESLint rules (auto-fixed on save)
The same Prettier config (format on save)
The same commit message format (enforced by Husky)
The same VS Code extensions (auto-installed)

PR reviews went from "please fix your formatting" to "let’s discuss the architecture."

5. Zero-Effort Config Updates

When a senior developer wants to:

1. Add a new ESLint rule → Push to config repo → Everyone gets it tomorrow
2. Update Docker base image → Push → Auto-synced
3. Add a VS Code extension → Push → Auto-installed
4. Fix a bug in the exception filter → Publish common-lib → Auto-updated No Slack announcements needed. No "please run npm install" messages. It just happens.

6. Standardized Project Structure
Every service looks the same. A developer can jump from user-service to payment-service and immediately know where everything is. The src/common/ folder has the same patterns. The Docker setup is identical. The health check endpoint is at the same path.

What We Learned

Start Small

We didn’t build this all at once. We started with just syncing ESLint and Prettier configs. Once the team saw the value, we added Docker, VS Code settings, the common library, and the auto-update system incrementally.

Don’t Force Everything

We allow service-specific overrides. If payment-service needs a special ESLint rule, they can add a .eslintrc.local.js that extends the shared one. The shared config is the baseline, not a straitjacket.

Notifications Matter
The desktop notification ("✅ Updated to config v1.2.0") was a small touch, but it made developers aware of the system. Before that, updates happened silently and people were confused when things changed.

Version Everything
The manifest.json version tracking was critical. Without it, the auto-update script had no way to know if anything changed, and it would waste time syncing configs that were already up to date.

The Complete Stack

Backend: NestJS (TypeScript)
Frontend: ReactJS (TypeScript)
AI: Qwen MCP
Containers: Docker, Docker Compose
Runtime: Node.js 20 LTS
Database: PostgreSQL 16
Cache: Redis 7
CI/CD: GitHub Actions
Editor: VS Code
Config Sync: Bash scripts + Cron

TL;DR
If your team has more than 3 microservices and more than 5 developers, you need a centralized dev environment config. Here’s the recipe:

Create a config repo with templates, shared configs, and scripts.
Write a setup script that onboards new devs in one command.
Write a sync script that copies shared configs to all services.
Set up a cron job that auto-updates every morning.
Create a shared NPM library for reusable code.
Build a service generator for scaffolding new microservices.

The result: developers spend their time writing code, not configuring environments.

Have you solved this problem differently at your company? I’d love to hear about it in the comments.
If you found this useful, give it a clap 👏 and follow for more microservices architecture deep-dives.

I Couldn't Afford AWS Cognito Experience — So I Built It Myself

Mehdi Hassan Jony — Tue, 28 Apr 2026 06:33:45 +0000

How open-source alternatives can land you the cloud job you're not "qualified" for

The job posting said "AWS Cognito experience required." I had never touched Cognito. I had never paid an AWS bill above the free tier. I almost closed the tab and moved on.

Two weeks later, I got called into the interview anyway. And I was ready.

Here's the uncomfortable truth about tech hiring: companies post aspirational requirement lists. They know the talent pool is wider than their wishlist. They shortlist you anyway. The question isn't whether you'll face that room — it's whether you'll be prepared when you do.

The concepts are what matter. The brand name is just packaging.

I'm going to show you the exact open-source alternatives I used to build enterprise-level knowledge without an enterprise budget. By the end of this, you'll have a map, a 30-day plan, and the exact words to use in your next interview.

What Interviewers Are Actually Asking

When someone asks "Have you used AWS Cognito?", they're really asking:

Do you understand OAuth2, SAML, SSO, MFA, and RBAC?
Can you reason about authentication flows in a distributed system?
Have you actually built something that handles identity?

I've been on both sides of this table. When a candidate says "I haven't used Cognito, but I self-hosted Keycloak, configured OAuth2/OIDC flows, set up LDAP federation, and implemented MFA" — that answer impresses me more than "Yes, I clicked through the Cognito wizard once."

Open source teaches you what managed services hide. You're not just consuming abstractions — you're wrestling with the actual systems.

The Stack: Enterprise Cloud → Open Source Alternative

🔐 Identity & Auth

You need to know	You can build with
AWS Cognito	Keycloak, Authentik, ZITADEL
Auth0, Okta	SuperTokens, Ory

I started with Keycloak. One Docker command. Within an hour I had OAuth2 SSO running against a test app with MFA enabled. The concepts map 1:1 to Cognito.

Fun fact: Cognito isn't natively multi-tenant — you need a dedicated user pool per tenant. Keycloak handles this through realms. Understanding that architectural difference alone puts you ahead of candidates who just clicked "Create User Pool."

🗄️ NoSQL Databases

Enterprise	Open Source
DynamoDB	Apache Cassandra, ScyllaDB Alternator
Firestore	Supabase, PocketBase

Here's the thing about DynamoDB: it's built on the same research paper as Cassandra. The partition key model, the consistency levels, the distributed architecture — it's the same DNA.

ScyllaDB's Alternator goes a step further. It offers an actual DynamoDB-compatible API. I ran my AWS SDK code against it locally. Zero changes. That's legitimate DynamoDB development experience without touching an AWS account.

📨 Message Queues

Enterprise	Open Source
AWS SQS / SNS	RabbitMQ, NATS
AWS Kinesis	Apache Kafka, Redpanda

I configured RabbitMQ with dead-letter queues, topic exchanges, and consumer acknowledgments. When the interviewer asked about SQS, I could talk about every pattern they cared about — because they're the same patterns.

🔥 Backend-as-a-Service

Enterprise	Open Source
Firebase, AWS Amplify	Supabase, Appwrite, PocketBase

Supabase is the open-source Firebase. Postgres database, authentication, real-time subscriptions, file storage, edge functions — all runnable with a single docker compose up. I built a full-stack app on my laptop. When they asked if I understood the BaaS model, I could walk them through every layer.

🪣 Object Storage

Enterprise	Open Source
AWS S3, Azure Blob	MinIO

MinIO is S3-API compatible. Not metaphorically — literally. My SDK calls, presigned URL generation, bucket policies — identical surface. MinIO to S3 is a config change, not a rewrite.

⚡ The Nuclear Option: LocalStack

LocalStack simulates 45+ AWS services on your machine. DynamoDB, S3, SQS, Lambda, API Gateway, Cognito — same SDK calls, same Terraform configs, same everything. Point your endpoint to localhost instead of amazonaws.com.

This was how I built "AWS experience" without an AWS bill.

The Interview Framework That Works

When they ask about a tool you haven't used commercially:

1. Acknowledge.
"I haven't used Cognito in production."

2. Bridge.
"But I've built authentication systems with Keycloak — OAuth2/OIDC, multi-tenant realms, LDAP federation."

3. Go deeper.
"I configured MFA with TOTP and WebAuthn, and set up fine-grained authorization policies. These map directly to Cognito's user pool features."

I've watched interviewers visibly recalibrate their assessment after this kind of answer. You're no longer "the candidate without Cognito." You're "the candidate who understands identity systems at a depth most Cognito users don't."

My 30-Day Zero-Cost Roadmap

Here's exactly what I did. You can start today.

Week 1 — Identity

docker run keycloak
Configure a realm, users, OAuth2 client
Add MFA
Build a simple login flow in your preferred language

Week 2 — Messaging

docker run rabbitmq
Producer/consumer app with dead-letter queue
Then try Kafka, understand the difference
Be able to explain when you'd choose each

Week 3 — Data

MongoDB and Cassandra, both on Docker
CRUD API against each
Design partition keys for different access patterns
Try DynamoDB-compatible queries against ScyllaDB

Week 4 — Full Stack

docker compose with Supabase
Build a small app using auth, database, storage
Then simulate S3, SQS, DynamoDB with LocalStack
Push everything to GitHub with good READMEs

The Bottom Line

The developer who says "I built this with Keycloak, RabbitMQ, Cassandra, and MinIO — here's my repo" is demonstrating something better than managed service familiarity.

They're demonstrating that they seek understanding over convenience. That they build rather than configure wizards. That they'll know why something works, not just that a button exists.

The cloud services you're being asked about were built on open-source concepts. Cognito implements the standards Keycloak speaks. DynamoDB evolved from the same paper as Cassandra. S3's API is so dominant MinIO cloned it.

The knowledge transfers. It always does.

Start building. Document everything. Walk into that interview with something real.

What open-source alternative has been most useful in your career? I'm genuinely curious — drop it in the comments and I'll check it out.

I built a CLI that installs a production-ready Auth system into any NestJS project in < 5 mins

Mehdi Hassan Jony — Mon, 27 Apr 2026 03:41:26 +0000

The "Day One" NestJS Fatigue

Every time I start a new NestJS project, I get a brief moment of excitement... followed by the realization that I have to build Auth again.

We’ve all been there. You spend 3 days setting up:

JWT strategies and refresh token rotation.
Password hashing with Bcrypt or Argon2.
Passport strategies for Google/GitHub.
Database schemas for Users and Roles.
Docker Compose for Redis and Postgres.
Swagger docs so the frontend team stops asking for endpoints.

It’s the same 80% of code every time. So, I decided to automate it.

Introducing `@mehdijony/nestjs-user-service`

I built a CLI tool that doesn't just scaffold a new project—it installs a complete, high-performance user management engine into your existing project.

⚡️ The 5-Minute Setup

In your terminal, just run:

npx @mehdijony/nestjs-user-service init

The CLI kicks off an interactive session. It’s smart enough to detect your stack:

Package Manager: npm, yarn, pnpm, or bun.
ORM: Prisma, TypeORM, Mongoose, or Drizzle.
Environment: It reads your .env and docker-compose.yml to ensure zero conflicts.

🛠 What's under the hood?

I didn't want this to be "just another boilerplate." It’s built for senior-level requirements:

1. The Modular Architecture

It generates a src/user-service/ directory with a clean separation of concerns. It even injects the UserServiceModule into your AppModule automatically.

2. Multi-Driver Support

Whether you are a Prisma fan or a TypeORM veteran, the CLI generates the correct entities and repositories for your chosen database (Postgres, MySQL, MongoDB, etc.).

3. Safety First (The Rollback Engine)

This is my favorite feature. Modifying source code is scary.
Before the CLI touches a single line, it creates a Restore Point.

If you don't like the result, or something goes wrong:

npx @mehdijony/nestjs-user-service rollback

It uninstalls the packages, deletes the generated files, and restores your app.module.ts and .env to their exact original state. Zero footprint.

📦 Feature Checklist

Category	Features
Auth	JWT, Refresh Tokens, Magic Links, OTP, Social OAuth
Security	2FA (TOTP), RBAC, Rate Limiting, Account Lockout
Infra	Redis Caching, BullMQ/Kafka, S3 File Uploads
DevOps	Auto-Swagger, Health Checks, Docker Compose Merge

🚀 Why I built this

As a Backend Engineer, I want to spend my time on unique business logic, not re-writing the same AuthService for the 10th time. This tool is for the solo dev who needs to ship fast and the agency team that wants a standardized auth foundation across all projects.

Give it a spin

I'd love to get the community's feedback on this. If it saves you a few days of work, drop a star on GitHub!

NPM: [https://www.npmjs.com/package/@mehdijony/nestjs-user-service]
GitHub: [https://www.github.com/mehdijony/nestjs-user-service]

What feature should I add next? LDAP support? SAML? Let me know in the comments! 👇

How Claude Code Built My Dashboard with Almost No Effort

Mehdi Hassan Jony — Mon, 20 Apr 2026 03:31:58 +0000

I’ve built dashboards before. Usually, it means hours of structuring components, managing state, wiring APIs, and refining UI behavior.

This time was different.

I used Claude Code and reduced the entire process to a few precise prompts.

What I did

I described the system at a high level:

Backend: NestJS
Data source: APIs / database
Frontend: dashboard with analytics, charts, and tables

Then I iterated with small corrections instead of writing everything manually.

What changed

Instead of:

Writing boilerplate
Structuring folders manually
Debugging repetitive code

I focused on:

System design
Data flow
Edge cases

The AI handled:

Component scaffolding
API integration patterns
Basic UI logic
Where it actually helps

This approach is not magic. It works well when:

You already understand architecture
You can detect wrong outputs instantly
You guide the system with constraints

Without that, it breaks quickly.

What still matters
Code review is still mandatory
Security and validation are not guaranteed
Performance tuning still requires manual work
Final thought

The shift is real:
Development is moving from writing code → directing code generation.

Tools like Claude Code don’t replace engineers.
They compress execution time.

The bottleneck is no longer typing speed.
It’s clarity of thought.

Most developers rely on cloud AI tools. I switched to running AI locally using Ollama.

Mehdi Hassan Jony — Thu, 16 Apr 2026 05:07:17 +0000

No API cost. No latency. No data exposure.

I use it daily for:

code generation
debugging
SQL queries
documentation

Full breakdown:
https://medium.com/@shoyshab/using-ollama-locally-how-it-changed-my-daily-development-workflow-9a07045dcd6c

Building a Scalable Backend Architecture with NestJS, Kafka, and PostgreSQL

Mehdi Hassan Jony — Wed, 15 Apr 2026 09:37:03 +0000

Most backend systems collapse under scale not because of traffic, but because of poor architectural decisions made early. Tight coupling, synchronous dependencies, and weak data strategies create bottlenecks that are expensive to fix later.

Problem

Typical backend issues at scale:

API latency increases under load
Services become tightly coupled
Failures cascade across the system
Database becomes a bottleneck

Architecture Overview

An event-driven microservices architecture:

API Gateway (NestJS)
Microservices (NestJS)
Kafka (message broker)
PostgreSQL (database)

Flow:

Client hits API Gateway
Event is produced
Kafka distributes it
Consumers process independently
Data persists

Why This Stack

NestJS

Modular architecture
Dependency injection
Scalable structure

Kafka

High-throughput messaging
Decouples services
Enables async workflows

PostgreSQL

Strong consistency
Reliable transactions
Powerful querying

Event-Driven Communication

Producer:

this.kafkaClient.emit('order_created', data);

Consumer:

@MessagePattern('order_created')
handle(data: any) {
  // process event
}

Key Strategies

Failure Handling

Retry with backoff
Dead Letter Queues

Idempotency

Track processed events
Prevent duplication

Scaling

Horizontal scaling for consumers
Read replicas for DB

Real-World Use Case

In systems like logistics or trading platforms:

Orders trigger multiple services
Payments, inventory, notifications run independently
Failures don’t block the system

Takeaways

Design async-first
Avoid tight coupling
Plan for failure
Scale consumers, not just APIs

Full Article

https://medium.com/@shoyshab/building-a-scalable-backend-architecture-with-nestjs-kafka-and-postgresql-ae938465b39b