Syed's Blogs

 Kafka consumers commit offsets to track their progress in a topic. This "bookmark" tells Kafka which messages have been successfully processed, ensuring that if a consumer restarts or a rebalance occurs, it knows exactly where to pick back up.  Internally, these offsets are stored in a special, compacted internal topic named __consumer_offsets.  1.⁠ ⁠Automatic Commit (Default) By default, the consumer is configured to commit offsets automatically.  How it works: When enable.auto.commit is set to true, the consumer automatically commits the largest offset returned by the poll() method at a fixed interval. (When you call poll(), Kafka doesn't just give you one message; it gives you a batch of messages (e.g., 500 messages at once). The consumer tracks your progress by the highest number in that batch.) Frequency: Controlled by auto.commit.interval.ms (default is 5000ms or 5 seconds). Risk: This is the easiest method but can lead to data loss (if the consumer crashes af...

 https://www.baeldung.com/kafka-commit-offsets

Prompt: So why do we create consumer group in Kafka? Basically, we have a consumer group and each consumer assigned to one partition. So what happens is, we have topics on which the consumer is subscribed to. And if the topic is in one consumer group, so for example, there is a topic 1 in consumer group 1. So if there are three topics in that consumer group 1, so either of them, one of them will receive the message the producer produced to that consumer group. But if we have different consumer groups, so each of them will receive that message on their topic, either the topic, for example, if we have group 1, group 2, group 3, and in each group, we have topic 1, topic 1, topic 1. So when producer send the message, it will go to each group and each topic. But when we have the consumer group, single consumer group, and all topic 1 replicates itself three times, it will be sent to one of the topics. Okay, am I correct? Make an article on that with this same example and give me copy-paste c...

 OAuth2.0. is the authorization protocol used for authorization not authentication. Case: User wants to access some resources (Client to server communication)  - Step 1: hit url abc.xyz.com (this url is protected and any resources in it requires auth) - Step 2 (Authentication part done by spring security not oauth2): URL triggers login page to first validate who the user is. - Step 3: User authenticates and return the access code to the client (which is requesting resource). - Step 4: Now client have the access code, client will hit authorization server with the access code, and authorization server return access token. - Step 5: Now client have the access token, it takes the token to the resource server to get the resource. WHY NEED ACCESS CODE AND WHY NOT DIRECTLY ACCESS TOKEN???  - As the user is anom

  What is CORS CORS (Cross-Origin Resource Sharing) is a browser security mechanism that controls which origins (domains) are allowed to read responses from your server. Origin = protocol + domain + port https://app.com ≠ https://api.com ≠ http://app.com Why CORS was developed Browsers enforce the Same-Origin Policy (SOP) : A script from one origin cannot read data from another origin. Problem SOP caused: Legit frontend ( app.com ) couldn’t call backend ( api.com ) and read responses. CORS solution: Let the server explicitly whitelist trusted origins . How CORS works Simple request Browser sends: Origin: https://app.com Server responds: Access-Control-Allow-Origin: https://app.com → Browser allows frontend JS to read the response Preflight request (for complex requests) Browser first sends: OPTIONS /api Origin: https://app.com Access-Control-Request-Method: POST Server replies: Access-Control-Allow-Origin: https://app.com Access-Contro...

  CSRF (Cross-Site Request Forgery) A browser-based attack where a malicious site tricks a user’s browser into sending a request (with cookies automatically attached) to your application. When CSRF is enabled (default in Spring Security) Spring expects a CSRF token on every state-changing request (POST, PUT, DELETE). Token is generated server-side and must be sent back (header/form field). Protects against attacks that rely on browser + cookies . Meaning: Only requests coming from your legitimate frontend (which has the token) are accepted. What “disable CSRF” means http . csrf () . disable (); Spring stops validating CSRF tokens . Any request is accepted without CSRF token verification . Impact: You lose protection against browser-based CSRF attacks. But only matters if your app uses cookies/session authentication . Why it’s commonly disabled in REST APIs Because REST APIs typically: Are stateless Use Authorization headers (JWT/Bearer tokens...