Thoughts
Why I should care about a Rate Limiter?
your system need a rate limiter– To prevent the DDoS attacks,– reduce costs,– error handling – it prevents DDoS attachs – distributed denial-of-service attempts.– limits unnecessary strain on computing resources, saving infrastructure spend.– it avoid overloading on our workload – ensures our happy users don’t accidentally or maliciously hog resources and ruin the experience for …
Mistake we have to AVOID:
“Many engineer think – If my system is highly available, then I have disaster recovery.” Not necessarily. A system can be highly available and still have poor disaster recovery.
The crutches of your comfort zone
The crutches of your comfort zone may help you walk today, but they are the biggest enemy of your growth.
Serverless is not free — it’s a different kind of cost
Everyone sells serverless as ‘pay only for what you use’. But nobody talks about the cognitive overhead: cold starts, DLQ monitoring, distributed tracing across 10 Lambdas, and the fact that debugging is a completely different discipline. The cost moved from infra bills to engineering hours.
RxJS is still misunderstood after all these years
Most Angular developers I have mentored treat RxJS like a fancy callback. The shift to thinking in streams — composing, transforming, and timing data flows — takes months. But once it clicks, it changes how you design the entire state layer of an application.
interface vs. types in TS
The main concept interfaces offer over types is declaration merging. On the other side, types can do a lot more than interfaces (mapped types, conditional types, etc)
Monorepos are an organisational decision, not a technical one
You do not adopt Nx because it is cool. You adopt it when the pain of coordinating shared libraries across separate repos outweighs the simplicity of isolation. The tooling is good, but the real win is making team boundaries explicit through code structure.
Infrastructure-as-Code is a contract
When I write a CDK stack, I am not just provisioning resources. I am writing a contract: this is what the system looks like, reproducibly, forever. Drift from that contract is technical debt with real operational consequences. Treat it like application code — review it, test it, version it.