Building Scalable Social Network with Microservices Architecture

Microservices + Kafka + Saga: a prototype to understand, not to impress My team is starting to explore event-driven architecture, so I built a prototype with NestJS and Kafka so we could learn the patterns together. I used an e-commerce domain on purpose: it's easier to explain Saga with "order → stock → payment" than with the specific logic of our business. The patterns are the same. The goal wasn't to build "one more shop", but to face the problems that appear when you stop using a single DB and start communicating through events. Three things I wanted the code to actually solve: > Saga choreography with compensation: when a payment fails after stock has been reserved, products-service consumes payment.failed and releases the reservation automatically. Without this, a saga isn't a saga — it's a linear pipeline that breaks at the first failure. > Idempotency in 3 layers: StockReservation @@unique(orderId, productId) in products, Payment @unique(orderId) in payments, and status guards in orders that reject out-of-order transitions. Kafka can deliver events more than once; handlers have to be ready for that. > Real database-per-service: 4 independent Postgres instances, no cross-service foreign keys, no HTTP calls between services. IDs across services are flat references: each service stores only what it cares about from other entities. Stack: NestJS 11 (hybrid app: HTTP + Kafka consumer in the same process), Prisma 7 with adapter-pg, Kafka KRaft (no Zookeeper), PostgreSQL (4 production DBs + 4 for tests). The diagram above tries to tell the whole story in one image: the 5 Kafka topics, who produces and who consumes, the red compensation arrow, the Order state machine, and the 3 idempotency mechanisms. Repo: https://lnkd.in/ejXpxC49 Leaving it here in case it's useful as a reference, or if anyone wants to take a look and tell me what they'd do differently. #microservices #nestjs #kafka #saga #softwarearchitecture #backend

Been in backend-learning mode for a few weeks now — Kotlin, Spring Boot, distributed systems. This week I finally wrapped my head around Apache Kafka. Coming from Angular/TypeScript, I always assumed messaging systems were some scary black box. Turns out the mental model is beautifully simple. Here's what clicked for me: 🔑 Kafka is a distributed log, not a queue Unlike a typical message queue where a message disappears after it's consumed, Kafka keeps everything as an immutable log. Consumers read by tracking an offset — basically a bookmark in the stream. You can replay messages. That blew my mind. 📦 Topics + Partitions = horizontal scalability A topic is like a category ("payments", "user-events"). Each topic is split into partitions, and that's where the throughput magic happens — Kafka can handle millions of events per second because partitions can live on different machines. ⚡ Producers and consumers are fully decoupled The broker doesn't care who's listening. You can add 10 new consumers without touching a single producer. Coming from a frontend world where everything is tightly coupled through APIs, this felt like a superpower. The analogy I keep using: Kafka is like a YouTube channel. Videos (messages) get published to a channel (topic). Any subscriber (consumer) can watch from any point — and the video doesn't disappear just because you watched it. Still getting my head around consumer group rebalancing and exactly-once delivery semantics — but the core mental model finally makes sense. If you're a frontend dev curious about backend — start with Kafka. It'll rewire how you think about data flow entirely. What resources helped you level up on distributed systems? Drop them below 👇 #Kafka #BackendDevelopment #LearningInPublic #FullStack #SoftwareEngineering #Kotlin

Just shipped my most complex backend architecture yet! Meet FoodRush—a fully decoupled, event-driven food delivery platform. 🏎️💨 I built this project to put advanced system design patterns into practice. No central orchestrator, no monolithic database, and no synchronous bottlenecks during heavy loads. The Engineering Highlights: ⚡ Event-Driven Core: Handled distributed transactions and rollbacks using SAGA Choreography over Apache Kafka. ⚡ Isolated State: 5 independent microservices (Java 21 / Spring Boot 3), each with its own isolated MySQL database. ⚡ Real-Time Speed: Built live driver tracking and split-bill "Group Carts" using WebSockets (STOMP) and Redis Pub/Sub. ⚡ AI Integration: Context-aware meal suggestions powered by the Gemini API. Check out the architecture diagram below to see how it all connects! 🔗 Source code & deep-dive documentation: https://lnkd.in/dkHYrSbK #SoftwareEngineering #Kafka #DistributedSystems #JavaDeveloper #BackendEngineering #SystemArchitecture

The "K8s + Kafka" Scaling Trap: Why Your Cluster is Fighting Itself ⚔️ The Hook: You set up KEDA to scale your GKE pods based on Kafka lag. Traffic spikes, 20 new pods spin up, and suddenly... your throughput drops to zero. You haven't crashed; you've just entered a "Rebalance Storm." The "Tricky" Problem: In a standard Microservices setup using Java Spring Boot and Docker, we treat pods as "disposable." But Kafka treats Consumer Groups as "stateful." When K8s adds a pod, Kafka stops everything to reassign partitions. If your JVM takes 30 seconds to "warm up" and pass a readiness check, Kafka thinks that consumer is dead and triggers another rebalance. You end up in a loop where your pods are too busy "joining the group" to actually process any data. The 15-Year Senior Architect's Fix: Static Membership: Switch your Kafka clients to use "group.instance.id". This tells the broker: "If this pod restarts, don't rebalance immediately. Wait for it to come back." Spring Native & GraalVM: If you are running on Cloud Run or GKE, use native compilation to drop startup times from 20 seconds to 200ms. This stops the "Readiness Check" from timing out during a scale-up. The "Buffer" Strategy: Don't scale on CPU. Use Custom Metrics in Grafana to scale on "Time-to-Process." It’s better to have 5 warm pods than 50 cold ones that are fighting for a partition. The Hybrid Bridge: For global events that don't need strict ordering, offload the "spiky" traffic to Google Pub/Sub. Let Pub/Sub handle the fan-out while Kafka handles the heavy-duty stateful streaming. The Hard Truth: Architecture isn't just about picking the best tools like GKE or Kafka. It's about understanding the "Physics" of how they interact. If your infrastructure and your messaging protocol aren't in sync, "scaling" is just a faster way to fail. The Takeaway: Stop scaling on "load" and start scaling on "readiness." #Kubernetes #ApacheKafka #GCP #Java #SpringBoot #Docker #SystemDesign #Microservices #CloudNative #SoftwareArchitecture #EngineeringLeadership #TechLead #DevOps #SRE

Building for Scale: My Journey with Distributed Systems I’ve spent the last few weeks diving deep into how modern backends handle high-concurrency and fault tolerance. I’m excited to share my latest project: Dist-Job-Processor. Instead of a simple task runner, I wanted to build something that mirrors real-world distributed architecture. Key Technical Highlights: - Engine: Built with Java and Spring Boot. - Task Queuing: Leveraged Redis for high-speed distributed queuing. - Persistence: PostgreSQL handles job states and historical data. - Observability: Integrated Prometheus for metrics and designed a custom Grafana dashboard to monitor system health and reconciliation stats in real-time. The real challenge wasn't just "making it work," but handling edge cases—ensuring job consistency across nodes and making the system truly observable. Check out the code and the dashboard setup here: https://lnkd.in/gMHmDkvN #Java #SpringBoot #DistributedSystems #Redis #Grafana #BackendEngineering #OpenSource #ITStudent

Everything works perfectly… until concurrency hits your system. One request becomes hundreds. One thread becomes many. And suddenly… your “working code” starts breaking. Let’s be clear: Concurrency is NOT just about threads. It’s about how your system behaves under pressure. There are 3 layers where most systems fail 👇 1️⃣ Application Lock Using synchronized, ReentrantLock, Atomic classes ✔ Fast ❌ Works only inside a single JVM → Breaks in distributed systems 2️⃣ Database Lock Optimistic (@Version) & Pessimistic locking ✔ Ensures data consistency ❌ Adds latency and contention 3️⃣ Distributed Lock Redis, Zookeeper, Hazelcast ✔ Works across multiple services ✔ Prevents duplicate processing (payments, schedulers) ❌ Complex and needs careful design And then comes the most misunderstood concept: Isolation Level. Most developers think @Transactional = safe. It’s NOT. Isolation defines how transactions see each other: → READ_COMMITTED → REPEATABLE_READ → SERIALIZABLE (strongest) SERIALIZABLE sounds perfect… But in reality? ❌ Slower ❌ Higher lock contention ❌ Possible deadlocks Real systems don’t rely on one solution. They combine: Application control + DB consistency + Distributed coordination That’s how scalable systems are built. Because in production… It’s not your logic that fails. It’s your concurrency design. ## #SystemDesign #SpringBoot #BackendEngineering #Concurrency #Microservices #Java

Modern microservices don’t become faster just by “breaking a monolith into services” — architecture decisions define performance. This transformation shows how moving from tightly coupled synchronous service chains (~2s latency) to an optimized event-driven architecture reduced latency by ~70% (to ~600ms). #Microservices #SystemDesign #Kafka #Redis #BackendEngineering #Scalability #SoftwareArchitecture #PerformanceOptimization #Nodejs #Java #CloudArchitecture

🚀 Most developers learn APIs… But the ones who understand event-driven systems build scalable systems that never break under pressure. Let’s talk about 🔥 Apache Kafka --- 💡 Imagine this: Instead of your services calling each other directly… They just publish events and move on. No waiting. No tight coupling. No chaos when traffic spikes. That’s Kafka. --- ⚡ Why Kafka is a game-changer for backend developers: ✅ Handle millions of events in real-time ✅ Build loosely coupled microservices ✅ Replay events anytime (yes, time travel ⏳) ✅ Fault-tolerant & highly scalable ✅ Backbone of modern data pipelines --- 🧠 Real-world use cases: 📌 Payment processing systems 📌 Real-time analytics dashboards 📌 Order tracking systems 📌 Log aggregation & monitoring 📌 Streaming platforms like Netflix --- ⚠️ Hard truth: If you’re only building CRUD apps… You’re missing the real backend engineering. --- 🎯 Want to stand out as a backend developer? Learn this stack: 👉 Java + Spring Boot 👉 Kafka 👉 Microservices 👉 Docker + CI/CD --- 💬 Comment “KAFKA” if you want a step-by-step roadmap 📌 Follow Narendra Sahoo for more real backend engineering content #BackendDevelopment #ApacheKafka #Java #Microservices #EventDriven #SoftwareEngineering #LearnToCode #TechCareers

Modern high-scale systems don’t fail because of weak hardware — they fail because of poor architectural decisions. When everything is synchronous, tightly coupled, and blocking under load, systems start collapsing at scale. This is exactly where event-driven architecture changes the game. In my latest blog, I’ve broken down how Apache Kafka enables: • Decoupled communication between services • Asynchronous, high-throughput processing • Fault-tolerant and scalable systems Read the full story below 👇 Follow TechBits@Argusoft for more such articles. #ApacheKafka #SystemDesign #DistributedSystems #BackendEngineering #EventDrivenArchitecture #Scalability #SoftwareArchitecture #TechBlog #Engineering #Java #Microservices #HighPerformance

Our Kubernetes pods kept crashing. The team wanted to increase memory limits. I refused. Here's how I reduced memory by 70% instead: 𝗧𝗵𝗲 𝘀𝘆𝗺𝗽𝘁𝗼𝗺 We were syncing 50,000+ product updates daily between two B2B platforms. Every few hours: OOMKilled. Pods evicted. Alerts firing. The quick fix was obvious: bump memory from 2GB to 4GB. Ship it. Move on. I pushed back. 𝗧𝗵𝗲 𝗶𝗻𝘃𝗲𝘀𝘁𝗶𝗴𝗮𝘁𝗶𝗼𝗻 I pulled heap dumps during peak sync. Found the culprit: our MongoDB patch operations were running inside nested loops, loading entire collections client-side — hundreds of thousands of documents pulled over the wire, filtered in Java memory, mutated, pushed back. The code worked fine with 1,000 products. With 50,000+ it was a time bomb. 𝗧𝗵𝗲 𝗳𝗶𝘅 (𝟯 𝗰𝗵𝗮𝗻𝗴𝗲𝘀) Replaced client-side filtering with MongoDB aggregation pipelines ($match, $project) — let the database do the work Added cursor-based pagination — never load more than 500 docs at once Configurable batch sizes — tune per environment without redeploying 𝗧𝗵𝗲 𝗿𝗲𝘀𝘂𝗹𝘁𝘀 → 70% memory reduction → 40% faster processing → Zero OOMKills after the fix → No pod spec changes needed 𝗧𝗵𝗲 𝗹𝗲𝘀𝘀𝗼𝗻 Increasing memory limits is not fixing a problem. It's hiding it. And it costs money every month. Before you scale up, scale smart: → Profile first (heap dumps, not guesswork) → Move processing server-side when possible → Paginate everything → Question the first assumption The most expensive line of code is the one that loads "everything" into memory. #Kubernetes #Java #MongoDB #Performance #SpringBoot #DevOps