Rakesh K

Go’s standard library is the reason it’s eating Node’s lunch on backends. Not because of benchmarks. Because of how backend projects actually feel to work on. A new Node project usually starts with decisions. Which framework, which logger, which validation library, which test setup. Before you’ve written a single route, you already have a stack: express, body-parser, helmet, cors, dotenv, winston, jest, ts-node. That flexibility is powerful. But it also means every project starts from zero. A Go project feels different. You import net/http, encoding/json, log, testing - and you start building. Most common backend needs are already handled, so the focus shifts from assembling tools to writing the service. That’s not a benchmark difference. It’s a design choice. Go pushes more into the standard library. Node pushes more into the ecosystem. Over time, that difference compounds. More dependencies → more version conflicts, more upgrade overhead, more time debugging things you didn’t write. Performance isn’t where this shows up. For most systems, both are fast enough. The difference shows up later - in maintenance, onboarding, and how predictable the system feels after a few months. Node optimizes for flexibility. Go optimizes for constraints. Both are valid choices, but they lead to very different day-to-day engineering. If a team spends more time wiring libraries than shipping features, it’s worth questioning the default. Not every backend needs to be minimal. But most teams benefit from fewer moving parts

What this file is ? Am I getting attacked ? It created either I ran npm i or wrangler deploy... any security expert here... help.

We all build horizontally scalable systems, but scaling is not as simple as saying "just add more machines" or "I will configure an autoscaling group". The challenge comes when we design systems that continue to behave predictably as traffic and load increase. Here are some common things you will run into and the pointers that will help you when you are building systems that scale horizontally: 1. Cache everything that can tolerate stale reads 2. Handle noisy neighbors with CPU/memory limits 3. Keep services stateless - scaling becomes easy 4. Databases do not scale easily - know your limits 5. Know your data access patterns before partitioning 6. Queue asynchronous work to absorb traffic spikes 7. Design for failure - retries, timeouts, fallbacks 8. Eliminate single points of failure 9. Make operations idempotent - handle retries safely 10. Understand consistency tradeoffs early 11. Invest in observability - metrics, logs, and tracing 12. Avoid distributed transactions where possible 13. Rate limit critical services and APIs 14. Scale reads and writes differently 15. Capacity planning still matters despite autoscaling By no means is this exhaustive, but these are some of the most common considerations that tend to surface as systems grow. Hope this helps.

Once when I was working in a company, I worked on a feature for simple invoice generation and communication. Everything was working fine. Clients were buying products. Application was saving it to DB. And invoice emails were being sent to them. These subprocesses were goroutines and we were using channels for communication between them. But one day server went down because of some hardware issue After some time server was up and running again perfectly fine. But after few hours we started receiving complaints: “we are not receiving invoice emails” Turns out those pending jobs were just data in the air sitting inside Go channels. And channels live in memory So when the process went down, those jobs vanished with it. That was the mistake here. Using channels like a real queue system. And the fix was also simple - PERSISETENCE Channels are great for communication between goroutines while the service is running. But if the work actually needs to survive restarts, crashes, or deployments, it shouldn’t be sitting only inside channels. That’s when queue systems like redis, rabbitMQ, apache kafka come in action Even today when I review Go codebases, I still see this mistake quite often. ♻️ Repost to help other developers in your network 👉 If you want to build scalable, high-performance backend systems without the guesswork, check out lnk.codersgyan.com/7ZVpH6N for deep, practical architecture training.

We hit a weird issue some time back while building a release orchestrator in Go. The services kept getting slower over time. Memory kept climbing. Restarting fixed it… temporarily. A few hours later: same issue. We were calling external build services like Jenkins from our core service. Some Jenkins requests never returned. And we weren’t propagating cancellation/timeouts properly. So goroutines just sat there waiting forever. They kept piling up. Memory growth wasn’t the root problem - goroutine leaks were. Memory was just the symptom. The fix was small, but it has two parts: 1/ Propagate r.Context() Go net/http gives you r.Context() for free. If the client disconnects, that context gets cancelled. But only code that listens to the context can stop. So pass it downstream. 2/ Add a hard timeout r.Context() only protects you from caller cancellation. It does not protect you if Jenkins hangs while your client is still waiting. So derive a child context: ctx,cancel := context.WithTimeout(r.Context(), 30∗time.Second) and use that for outbound calls. Now both failure modes are covered: • Client disconnects → cancelled • Jenkins hangs forever → cancelled after timeout Small change. Huge production impact. In Go, every outbound call should have context ownership.

@arpit_bhayani The sad reality of YT education. These days audience on YouTube are like: “Dimaag pe load nahi ana chahihe 😅”

I am showing how you can build Redis from scratch and nobody cares 😅 I will start posting commentaries and rants. Wahi dega views. This is my worst, absolute worst, performing series.

@amaan_1105 I have stopped the repo, many people started binge pr opens without understanding product vision 😅 In Golang course there will be another project. Will share updates about it.

@codersGyan I checked the camp repo. The last commit was 6 months ago, so I thought you had stopped the project. I’d suggest including this project in the upcoming Golang course. I’d also love it if the course were live instead of pre-recorded videos.

Spent the weekend deep in Camp, the open-source email marketing platform I’m building in Go. I started this thinking email marketing was basically : store emails, write campaigns, hit send. Turns out email is a distributed systems problem dressed as a SaaS feature. What I’ve already had to think through: - Some emails bounce temporarily. Some permanently. The retry logic changes completely. - When to retry , when to suppress, Hard bounce vs Soft bounce - Get DKIM/SPF/DMARC wrong and emails quietly land in spam folders. - Gmail throttles differently from Outlook. Outlook behaves differently from Exchange. - If a worker crashes mid-batch, retries can accidentally send duplicate emails. - Even tracking opens and unsubscribe links become separate HTTP endpoints to maintain. I thought I was building a CRUD app with a send button. I’m actually building a queue, a worker pool, a delivery layer, and a state machine. Almost every backend problem looks simple until you ship it. That’s the part tutorials usually skip.

Most “system design” content online is performance theater. People are learning how to “design Twitter for 1B users” before they understand what a primary key is. The order is backwards. 1/ Start with Low-Level Design. Schemas, API contracts, error handling, data relationships, what happens when input is wrong. That is the boring 90% of real engineering. 2/ Then move to High-Level Design. Sharding, caching, queues, regions. But only after you understand what is actually being sharded, cached, or queued. 3/ Then learn trade-offs. CAP, latency vs cost, consistency vs availability. These only become useful when you have something concrete to apply them to. A lot of engineers can draw a Twitter timeline diagram. Ask them to design the schema for posts, likes, comments, and reactions. They freeze. HLD without LLD is fan fiction. Build the data model. Earn the architecture diagram.

Get Backend foundation right: codersgyan.com/courses/backen…

Go’s standard library is the reason it’s eating Node’s lunch on backends. Not because of benchmarks. Because of how backend projects actually feel to work on. A new Node project usually starts with decisions. Which framework, which logger, which validation library, which test setup. Before you’ve written a single route, you already have a stack: express, body-parser, helmet, cors, dotenv, winston, jest, ts-node. That flexibility is powerful. But it also means every project starts from zero. A Go project feels different. You import net/http, encoding/json, log, testing - and you start building. Most common backend needs are already handled, so the focus shifts from assembling tools to writing the service. That’s not a benchmark difference. It’s a design choice. Go pushes more into the standard library. Node pushes more into the ecosystem. Over time, that difference compounds. More dependencies → more version conflicts, more upgrade overhead, more time debugging things you didn’t write. Performance isn’t where this shows up. For most systems, both are fast enough. The difference shows up later - in maintenance, onboarding, and how predictable the system feels after a few months. Node optimizes for flexibility. Go optimizes for constraints. Both are valid choices, but they lead to very different day-to-day engineering. If a team spends more time wiring libraries than shipping features, it’s worth questioning the default. Not every backend needs to be minimal. But most teams benefit from fewer moving parts

Backend foundation: codersgyan.com/courses/backen…

The Backend Foundation course at Coder's Gyan. Here’s who it’s NOT for 1/ You want a quick certificate for LinkedIn next week 2/ You want “10 backend tools to learn in 2026” 3/ You want Express middleware syntax explained from scratch. There’s already a youtube tutorial for that. 4/ You want a backend role in 4 weeks without having built systems before You’ll probably hate this course. This pace is slower. The work is harder. A lot of time goes into understanding systems, not memorizing frameworks. Who it IS for 1/ Engineers who can already code, but still don’t fully understand TCP, HTTP, or query planning 2/ Frontend developers trying to move beyond just consuming APIs 3/ Mid-level engineers stuck for years because they learned frameworks before systems. 13 weeks. Networks before frameworks. SQL before ORMs. Why before how. If that sounds like the gap you’re trying to close, the link is in the comments.

𝗧𝗵𝗲 𝗧𝗮𝗻𝗦𝘁𝗮𝗰𝗸 𝗻𝗽𝗺 𝗲𝗰𝗼𝘀𝘆𝘀𝘁𝗲𝗺 𝘄𝗮𝘀 𝗰𝗼𝗺𝗽𝗿𝗼𝗺𝗶𝘀𝗲𝗱 𝗶𝗻 𝗮 𝗰𝗼𝗼𝗿𝗱𝗶𝗻𝗮𝘁𝗲𝗱 𝘀𝘂𝗽𝗽𝗹𝘆 𝗰𝗵𝗮𝗶𝗻 𝗮𝘁𝘁𝗮𝗰𝗸. 84 malicious package versions across 42 @tanstack/* packages were pushed to npm on 11 May 2026, between 19:20 and 19:26 UTC. This is one of the most serious npm incidents the JavaScript ecosystem has seen this year. Here is what happened and what it means for developers. 𝗪𝗵𝗮𝘁 𝗵𝗮𝗽𝗽𝗲𝗻𝗲𝗱 An attacker published 84 malicious versions across 42 packages in the @tanstack namespace. @tanstack/react-router alone gets over 12 million weekly downloads. The tarballs were signed by TanStack's legitimate release pipeline with valid SLSA provenance, which means they were technically indistinguishable from real releases. 𝗛𝗼𝘄 𝘁𝗵𝗲 𝗮𝘁𝘁𝗮𝗰𝗸 𝘄𝗼𝗿𝗸𝗲𝗱 The attacker chained three weaknesses, none of which would have been enough on its own. 1/ A pull_request_target workflow that checked out and ran code from an attacker-controlled fork 2/ GitHub Actions cache poisoning across the fork and base trust boundary, planting a malicious pnpm store that survived into the next legitimate release run 3/ OIDC token extraction from the runner process memory at /proc//mem, which gave the attacker a publish-capable npm token without ever stealing a credential This is the same Mini Shai-Hulud worm family that hit Bitwarden CLI in April and Trivy in March. 𝗪𝗵𝗮𝘁 𝘄𝗮𝘀 𝗶𝗻𝘀𝗶𝗱𝗲 𝘁𝗵𝗲 𝗺𝗮𝗹𝗶𝗰𝗶𝗼𝘂𝘀 𝗽𝗮𝗰𝗸𝗮𝗴𝗲𝘀 The payload was a credential stealer targeting AWS, GCP, Kubernetes, HashiCorp Vault, GitHub tokens, SSH keys, and .npmrc files. It also self-propagated, using stolen OIDC tokens to publish into any other npm scope the compromised CI had access to. On some hosts, it attempted a full disk wipe. 𝗪𝗵𝗮𝘁 𝗶𝘁 𝗺𝗲𝗮𝗻𝘀 𝗳𝗼𝗿 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿𝘀 𝘄𝗵𝗼 𝗶𝗻𝘀𝘁𝗮𝗹𝗹𝗲𝗱 𝗮𝗻 𝗮𝗳𝗳𝗲𝗰𝘁𝗲𝗱 𝘃𝗲𝗿𝘀𝗶𝗼𝗻 𝗼𝗻 𝟭𝟭 𝗠𝗮𝘆 1/ Treat the install host as compromised 2/ Rotate AWS, GCP, Kubernetes, Vault, GitHub, npm, and SSH credentials reachable from that host 3/ Audit CI runs after 19:20 UTC for unexpected npm publish events Check for outbound connections to filev2.getsession.org and api.masscan.cloud 𝗪𝗵𝗮𝘁 𝗶𝘁 𝗺𝗲𝗮𝗻𝘀 𝗳𝗼𝗿 𝘁𝗵𝗲 𝘄𝗶𝗱𝗲𝗿 𝗲𝗰𝗼𝘀𝘆𝘀𝘁𝗲𝗺 TanStack's postmortem was public within hours. Tanner Linsley named the three vulnerabilities, walked through the full chain, and shipped concrete recommendations. That is the response engineering teams should study. The deeper problem is structural. OIDC trusted publishing binds an identity, not a specific build step. Once configured, any code path in the workflow can mint a publish-capable token. Provenance signed it. The registry accepted it. Nothing was technically wrong. 𝗧𝗵𝗲 𝗯𝗶𝗴𝗴𝗲𝗿 𝗹𝗲𝘀𝘀𝗼𝗻 Supply chain security is not a checklist. It is a property of how your CI is wired. The defaults look safe in isolation. pull_request_target runs on PRs. GitHub Actions caches everything to speed up builds. OIDC removes long-lived secrets. Each of those is reasonable on its own. Chained together by an attacker who understands the trust model, they ship malware through your own release pipeline with valid signatures. The difference between a junior and a senior backend engineer shows up exactly here. One writes code. The other owns the system and asks what the defaults compose into when something goes sideways. If you ship npm packages, read the TanStack postmortem this week. It is the cheapest tuition you will pay this year. What is your CI doing on pull_request_target right now?

Distributed systems are not just defined by what we put into them. They are equally defined by what we leave out. Let me give you 4 examples... Take timeouts - A service with no timeout on an outbound HTTP call will wait indefinitely. Under load, all its worker threads pile up waiting, and the service effectively becomes unavailable. No one 'decided' to make it unavailable. They just forgot to decide how long to wait. Or retries - If your service does not retry a failed downstream call, the data gap it creates can look like a bug in a completely unrelated service days later. What was omitted from the retry strategy is now an incident. Take acknowledgements - When you fire a message to a queue and do not wait for an ack, you just chose to tolerate message loss. That choice is not written anywhere in your architecture diagram. It lives silently between the producer and the broker. The same logic applies to back-pressure. If you do not model what happens when a consumer is too slow, the producer keeps going, memory climbs, and the system falls over. The crash was not caused by what was built. It was caused by what was not built. Hence, while reviewing a distributed system design, we should ask: - what happens when this message is lost, - what happens when this call never returns, - what happens if this node never comes back? The answers you do not have are where the failures live. Hope this helps.

@amaan_1105 Next year koshish karenge 😊

@codersGyan system design the course kab laraheho sir. Itna kuch free me parhao ge kya ?

Connection pooling in Postgres. Postgres uses a process-per-connection model not thread-per-connection. That means every connection is expensive : memory, file descriptors, process overhead. Now the connection math matters. A default pool of 100 connections is roughly ~1GB of RAM before queries even run. 4 app servers x 100 connections = 400 connections. Postgres defaults to max_connections = 100. Now the database starts refusing connections. The fix usually isn’t “add more connections.” It’s a connection pooler. PgBouncer in transaction mode is the standard answer. Apps connect to PgBouncer (cheap). PgBouncer multiplexes them onto a much smaller pool of real Postgres connections (expensive). 1,000 app connections can fan into 20 actual DB connections. Before reaching for it, read the caveats. Prepared statements, session-level state, advisory locks.. all behave differently. If your scaling plan is just increasing max_connections, you probably don’t need a bigger database. You need PgBouncer.

SECURITY ADVISORY — TanStack npm packages A supply-chain compromise affecting 42 @tanstack/* packages (84 versions total) was published to npm earlier today at approximately 19:20 and 19:26 UTC. Two malicious versions per package. Status: ACTIVE — packages are deprecated, npm security engaged, publish path being shut down. Severity: HIGH — payload exfiltrates AWS, GCP, Kubernetes, and Vault credentials, GitHub tokens, .npmrc contents, and SSH keys. If you installed any @tanstack/* package between 19:20 and 19:30 UTC today, treat the host as potentially compromised: • Rotate cloud, GitHub, and SSH credentials immediately • Audit cloud audit logs for the last several hours • Pin to a prior known-good version and reinstall from a clean lockfile Detection — the malicious manifest contains: "optionalDependencies": { "@tanstack/setup": "github:tanstack/router#79ac49ee..." } Any version with this entry is compromised. The payload is delivered via a git-resolved optionalDependency whose prepare script runs router_init.js (~2.3 MB, smuggled into each tarball at the package root). Unpublish is blocked by npm policy for most affected packages due to existing third-party dependents. All 84 versions are being deprecated with a SECURITY warning, and npm security has been engaged to pull tarballs at the registry level. Full technical breakdown, complete package and version list, and rolling status updates: github.com/TanStack/route… Credit to the security researcher for responsible disclosure.

A lot of teams move to GraphQL because they wrote bad REST. REST is not dead. The API design usually is. The symptoms tend to look the same : - /users returning 47 fields when the client needs 4 - List endpoints with no pagination - Action endpoints like /users/123/activate when a PATCH would do - Status codes that don’t distinguish bad input from server failures - Versioning by environment instead of in the API itself GraphQL doesn’t automatically fix bad REST. It can just hide bad API design behind a cleaner query layer, until your N+1 problem becomes graph-shaped. gRPC doesn't fix it either. Now debugging is harder because the wire format isn’t human-readable. Most teams don’t need a new API paradigm. They need better endpoint design. Spend a week improving your /users endpoint before spending a year migrating away from REST

5 questions to answer before splitting your monolith. 1/ Are deploys actually blocking the team? If two engineers occasionally step on each other, probably not. If 20 engineers are coordinating deploys every day, maybe. Microservices solve coordination problems first. 2/ Do different parts of the system have genuinely different scaling needs? Auth at 100 RPS and search at 10k RPS are different problems. If everything scales together anyway, you’ve just created multiple deploys for the same workload. 3/ Can you actually debug across services? Distributed tracing. Structured logs with correlation IDs. Altering per service. Without those, a microservice outage becomes a needle in a haystack search that can take hours to resolve. 4/ Can you afford the latency tax? Every network hop adds overhead. A request touching five services adds latency before real work even starts. 5/ Are services owned by clear teams? Microservices are an organizational pattern as much as a technical one. Without ownership, you don’t get independent services. You get a distributed monolith. If the answer to most of these is “no”, don’t split yet. Modularize the monolith. Revisit the decision later.

Every junior backend engineer I interview struggles with the same Postgres question. “What’s the difference between a clustered and non-clustered index?” The interesting part : Postgres doesn’t really have “clustered indexes” the way SQL server does. In Postgres, indexes are separate data structures pointing back to rows in the heap. What it does have is the “CLUSTER” command. It physically reorders a table on disk to match an index’s order. Done once. Not automatically maintained. Mostly useful in analytics-heavy workloads. But that’s usually not what the interviewer is testing for. What they actually want to know: - Do you understand what an index is? - Which queries it helps - And which queries it can’t A lot of people memorize database answers. Very few can explain a B-tree to a smart non-engineer. That difference is what that quickly shows up in interviews Don’t study database facts in isolation. Build something. Run EXPLAIN. Watch queries behave with and without indexes That understanding sticks.