Ashok Sahoo

An API Gateway is not just a reverse proxy. It’s the control plane in front of your services. If you’re building microservices and don’t have one, your architecture will eventually get messy. Here’s what it actually does 👇 What is an API Gateway? It’s a single entry point that sits between clients and your backend services. Instead of: Client → Service A Client → Service B Client → Service C You have: Client → API Gateway → Internal Services The gateway handles cross-cutting concerns so your services don’t have to. What does it do? An API Gateway typically handles authentication, authorization, rate limiting, request routing, response aggregation, logging, monitoring, and sometimes caching. It can: - Validate JWT tokens - Enforce rate limits - Route /users to User Service - Route /payments to Payment Service - Combine multiple service responses into one Your microservices stay focused on business logic. When do you need it? You likely need an API Gateway when: - You have multiple microservices - You want centralized authentication - You need rate limiting at the edge - You want to hide internal service structure - You are exposing public APIs If you have a simple monolith, you probably don’t need one yet. Common real-world examples: Netflix, Amazon, and most SaaS platforms use API gateways to manage traffic at scale. Popular solutions include: - NGINX - Kong - AWS API Gateway - Envoy Without an API Gateway: Every service reimplements auth, logging, and rate limiting. With an API Gateway: Infrastructure concerns are centralized and standardized. It’s not just traffic routing. It’s architecture discipline. Building microservices? Repost. Follow. Bookmark this.

Most bugs come from assumptions. “We thought it would…” “It should work because…” “This case won’t happen…” Reality disagrees. Verify: • inputs • outputs • edge cases • real data Assumptions break systems.

@IamMadhanMohan Yeah. The key is isolating affected records fast.

@ashoKumar89 Recovery: Stop the job, identify affected records, and restore them using transaction logs / point-in-time recovery instead of a full backup. Prevention: Take a snapshot before migration, run in batches, and add validation + rollback mechanisms.

A data migration runs for 8 hours. It corrupts 50K records. You need to roll back. But your latest backup is 12 hours old. You cannot lose that data. What’s your recovery strategy? And how do you prevent this in the future?

@anirudhology Good approach. The real win is being able to identify exactly what the migration touched.

Oh, that's a pickle, but we can take the following careful approach to get out of this jam. 1/ Restore the 12 hour backup to a separate recovery instance. 2/ Replay the WAL upto the exact timestamp just before the migration started. This recovers all valid data added after the backup. 3/ The corrupted 50K records are isolated by identifying all rows touched by the migration (using txn ID or explicit audit columns) and either deleting them or restoring their pre-migration values from a shadow table or logical decoding snapshot. To stop this happening in the future, we must run migrations inside a database transaction with a "rollback" plan: take a fresh snapshot immediately before the migration, use a temp staging table to validate changes before swapping them into place, and always have point-in-time-recovery (PITR) enabled.

@krunalbuilds Good list. Once you isolate one bad node, the pattern usually reveals itself.

First checks: • Which instances are failing? (compare good vs bad) • Recent deploy diff / config mismatch • Health checks + load balancer routing • Dependency issues (DB, cache, third-party) • Resource limits (CPU, memory, connections) • Timeouts/retries misconfigured Goal: find what’s different between healthy and failing nodes.

You deploy a critical update. 30% of requests start timing out. Failures are inconsistent across instances. You cannot roll back immediately. What do you investigate first?

@won__sikkk I would not call 10 minutes unrealistic here. It is achievable but only with the right architecture.

@ashoKumar89 How do you handle the PM conversation when they give you an unrealistic timeline like 10 minutes?

You need to process 10 million user notifications. Sending them synchronously would take 28 hours. Your product manager wants it done in 10 minutes. How do you architect this? Bonus: What happens if the notification service goes down mid-process?

@krunalbuilds Nice approach. How would you handle ordering if it matters?

Async + parallelism. • Push 10M notifications to a queue • Process with many workers in parallel • Batch + rate limit per provider • Use idempotency to avoid duplicates If service fails: • Queue holds messages • Retry with backoff • DLQ for failures • Resume safely without losing work

Performance bottlenecks that are not in your code: - DNS resolution taking 200ms because of recursive lookups - Connection pool exhaustion from short-lived connections - Kernel TCP buffer sizes limiting throughput on fast networks - GC pauses from allocating objects in tight loops - Context switching from too many threads, not too few - Memory bandwidth saturation from poor cache locality - Disk I/O from logging, not from your database Profile the entire stack, not just your application layer. What would you add to this list?

API Version in headers or in URLs? URLs are explicit but pollute logs and caches. Headers are cleaner but less transparent. Which approach do you use in production?

@jb_61820 How do you handle cross-service data consistency?

I'm a big fan of "fat microservices". Essentially, have a collection of monoliths, but shared auth, all behind a gateway. This allows each team to work on their monolith independently - doesn't even have to be the same tech stack. If they wind up discovering a shared service they all use, they can break that out, too, but the focus is on everyone having ownership over their own project space.

Monoliths are simpler. Microservices add latency and complexity. Yet teams keep breaking systems into smaller services. What trade-off are they willing to accept?

@IamMadhanMohan Agree on internal vs public split. Headers are fine… until scale + infra gets involved.

@ashoKumar89 Use URL versioning in production. It’s more explicit, easier to debug, cache-friendly, and avoids hidden behavior. Headers are fine for internal or experimental APIs, but they reduce visibility and can cause subtle issues.

@LacTranAn Splitting by flow creates chatty services and latency.

Imo, microservices should be broken down by two factors: - Logical responsibility: this creates a reasonable boundary for services - Scalability: consider for scaling. So in case one part of the system receives more traffic, we can scale it horizontally. For me, the nightmare is when the team breaks flow into services, communicating back and forth by events.

@magadum_aniket ORMs are easy to use, hard to reason about without fundamentals.

@ashoKumar89 It’s important to understand the fundamental working of the ORM before using them.

ORMs make development faster. But can hide inefficient queries. Why do teams still rely on them heavily?

@McClellandRuss This is one of the reason. But for complex queries raw SQL are way better than ORM

@ashoKumar89 Developers are too lazy to learn database mechanics and SQL.

@IamMadhanMohan True… but by the time it “hurts”, it is usually expensive to fix.

@ashoKumar89 ORMs speed up development, reduce boilerplate, improve maintainability, and let teams work faster with fewer bugs. Most inefficiencies can be fixed when needed, so teams accept that risk to gain productivity upfront.

@EvyTechno Exactly. Reviews are about shared understanding, not just correctness.

Mostly true — but incomplete. Code reviews do catch mistakes. That’s just the lowest level of value. The real purpose is: synchronize mental models across the team Sharing context → so knowledge isn’t siloed Improving design → so decisions are intentional, not accidental Aligning standards → so the codebase stays coherent Reducing future bugs → by fixing thinking, not just syntax But here’s the deeper layer people miss: A good review answers: “Will this still make sense 6 months from now under load, change, and failure?” Because bad code isn’t just buggy — it’s hard to reason about, hard to extend, and easy to misuse. Also: If your review is only happening at PR time, you’re already late. Strong teams push this earlier: - design discussions - clear interfaces - small, reviewable changes So yeah — reviews improve the system. But only if they move beyond “what’s wrong” to “is this the right way to think about the problem?”

Code reviews are not for finding mistakes. They are for: • sharing context • improving design • aligning on standards • reducing future bugs A good review improves the system. Not just the code.