Posts

How Binary Exponentiation Helps Us Find Prime Numbers

From “Is this number prime?” to “We can test this fast—even for huge numbers” At first glance, prime numbers feel like a school topic. But then you step into: cryptography security systems distributed systems blockchain authentication protocols And suddenly, primes aren’t academic anymore — they are foundational to modern computing . The real question becomes: How do we check whether a number is prime when the number itself is enormous? That’s where binary exponentiation quietly becomes one of the most important tools you’ll ever learn. Scene 1: The Naive Prime Check (and why it breaks) Let’s start simple. To check if a number n is prime, the basic idea is: try dividing n by numbers from 2 to n-1 This works… until it doesn’t. Why this fails in real systems If n has 100 digits , you cannot try dividing it Even checking divisibility up to √n is impossible Cryptographic primes are hundreds or thousands of bits long At this point, brute force is dead. So engineers asked a smarter qu...
Post a Comment
Read more

Binary Exponentiation & Modular Arithmetic

From “Why is this confusing?” to “This is obvious now” Some concepts in computer science don’t feel hard because they are complex — they feel hard because we try to compute instead of understanding . Binary exponentiation is one such concept. This blog captures a real learning journey: starting with confusion around large exponents and modular arithmetic , and ending with a clear, reusable mental model you’ll never forget. 1. The Problem That Started It All We were asked to compute: 2¹⁰¹ mod 7 At first glance, it feels intimidating: 101 is a large exponent Direct multiplication is impossible Modulo arithmetic feels tricky But the key realization is this: The problem is not “big numbers” — the problem is “wrong approach”. 2. Why Naive Exponentiation Fails The naive way: 2 × 2 × 2 × … (101 times) Problems: Takes O(n) time Numbers grow extremely large Completely impractical in real systems In cryptography , competitive programming, and system algorithms, this approach is unusable. So th...
Post a Comment
Read more

🚀 A Practical Coursera Roadmap for Java, CS, Concurrency, DevOps & Data Science

Learn by examples, not memorization — for long-term engineering growth Most engineers search for “best course for Java / Kafka / DevOps” . The real question should be: Which courses build thinking that still helps after 5–10 years? This blog is a discussion-driven roadmap , not a marketing list. Every recommendation below is chosen because it: Builds mental models Explains why systems behave the way they do Helps in service-based + product-based interviews Pays off in real production systems 🧠 First: How to Think About Learning (Important) Learning tech stacks without fundamentals is like: Buying power tools without understanding wood 🪚 Driving fast without knowing brakes 🛑 So the roadmap flows like this: Computer Science & Concurrency → how machines behave Java (Modern) → how code executes Spring, WebFlux, Kafka → how services communicate DevOps & Cloud → how software reaches users Data Science → how systems learn from data 1️⃣ Computer Science & Concurrency (The ...
Post a Comment
Read more

Tomcat vs Jetty vs GlassFish vs Quarkus — A Deep, Story-Driven Guide (with Eureka)

  A blog that makes the choice crystal clear for both freshers and senior engineers The story: SkyHospital’s Java journey (and why “server choice” is never random) Meet SkyHospital — a product company building hospital software: Admin portal for hospital staff Doctor dashboard Patient appointment booking Billing & reports Notifications (email/SMS/WhatsApp) Eventually: multiple microservices They start small, then grow, and at each stage their “best server choice” changes. This is exactly how it happens in real life. Chapter 1 — The first release (Tomcat enters) SkyHospital’s first app is a single codebase: JSP pages for Admin UI Spring MVC controllers A couple of servlets and filters Simple SQLite database (for MVP) Packaged as a WAR file Deployment reality: The company has: 1 VM 1 admin who restarts services A release once a week Minimal monitoring The CTO says: “I want something stable that every Java engineer understands.” ✅ Why they choose Tomcat Tomcat is a servlet contai...
Post a Comment
Read more

Real‑Time Stock Trading Dashboard Updates

How to update hundreds of UI components instantly when a new Buy Order is created Trading UIs feel “alive” because they react to backend events in milliseconds: order book rows move, depth changes, charts tick, alerts fire, and positions recalc—often at the same time . In interviews, this question tests whether you can design a system that’s: Low latency (real-time UX) Scalable (many users, many symbols, many updates/sec) Efficient (don’t re-render everything) Correct (ordering, duplicates, reconnection) Secure (authz, least privilege, data boundaries) This blog explains a production-grade approach you can reuse long-term. 1) The core challenge Event: Backend receives/creates a new Buy Order Requirement: “ Update 100s of UI components instantly ” Hidden complexity: Not every component cares about every order Updates can be bursty (market open, news spikes) UIs must survive disconnects and still be correct You can’t blast full snapshots repeatedly without melting bandwidth and ...
Post a Comment
Read more

DB Isolation Levels (ACID) Explained — From Dirty Reads to Serializable (with Spring Boot examples)

Picture this: you and your friend are trying to book the last movie ticket on a Saturday night. You both open the app, see “1 seat left”, and smash the “Book Now” button at the same time. In one universe: only one of you gets it (correct). In another universe: both of you get “Booking confirmed” (😬 oversold seat). In the worst universe: the app charges both of you and then refunds one later (support ticket nightmare). That “multiple people doing things at the same time” problem is what transaction isolation is trying to make boring, predictable, and safe. ACID in 2 minutes (but we’ll zoom into “I”) ACID is a set of guarantees databases try to provide for transactions: A — Atomicity : All or nothing (either the booking is done, or it’s as if it never happened). C — Consistency : Constraints/invariants hold (no negative inventory, no duplicate unique keys, etc). I — Isolation : Concurrent transactions shouldn’t step on each other in surprising ways. D — Durability : Once committed, i...
Post a Comment
Read more

PACELC, Paxos, and Raft: How “Consistency vs Latency” Shows Up in Real Systems

Distributed systems design is mostly about choosing which pain you’re willing to live with—because you can’t eliminate it. The PACELC theorem is a practical lens for those choices, and Paxos and Raft are two of the most important tools engineers use when they decide “we’re going to pay latency to buy correctness.” This post ties them together: PACELC tells you what trade-off you’re making Paxos/Raft are two ways to implement the “consistent” side of that trade-off You’ll see concrete examples, message flows, and how partitions change behavior Why CAP isn’t enough, and why PACELC exists You likely know the CAP -style story: P artition happens → you must choose C onsistency or A vailability. The missing piece is: most of the time you’re not partitioned —you’re just dealing with latency, replication delay, tail latencies, and node slowness. PACELC adds the everyday reality: If there is a Partition (P) : you choose Availability (A) or Consistency (C) Else (E) (normal operation, n...
Post a Comment
Read more