Scroll LinkedIn for five minutes and you’ll see it.

“Built a full app in one weekend. Zero code.”

“AI agents will replace developers by next year.”

“Software engineering is dead.”

And in the comments, the same worried question again and again:

Should I even bother learning to code anymore?

If you’re a student grinding DSA at 1 AM, or a developer a few years into your career, that hits hard. I get it.

So let’s skip the hype and the panic. Let’s look at three things instead: history, data, and the actual work.

1. We’ve heard this prediction before. Many times.

“Programmers will soon be useless” is not a new idea. It’s older than most of our parents.

• 1954: A report on FORTRAN said it would “virtually eliminate coding and debugging.”
• 1959: COBOL came with English-like code, so managers could “write programs themselves.”
• 1980s: CASE tools promised software without programmers.
• 2000s: “All coding jobs are moving offshore.”
• 2010s: No-code tools would make developers optional.
• Now: AI.

Here’s the twist. Every one of those tools actually worked.

And after every wave, the world needed more programmers, not fewer. When building software gets cheaper, people just want more software.

Every tool that made coding easier ended up creating more coding jobs, not fewer.

2. What the 2026 data actually says

Opinions are loud. Numbers are quiet. So let’s listen to the quiet ones.

The good news

• 67,000+ open software engineering roles, up about 30% this year and the highest in three years (TrueUp, via Business Insider).
• Top tech companies are hiring ~20% more engineers than last year (The Pragmatic Engineer, May 2026).
• Many big companies have 50–100% more AI engineering jobs than a year ago.

The honest news

• Layoffs are real: over 52,000 tech job cuts in Q1 2026 (Challenger, Gray & Christmas).
• Jobs asking for 5+ years of experience went from 37% to 42% (Indeed). Freshers have it tougher.

So the real picture is this:

The profession is growing. The entry bar has gone up. That’s a skill problem, and skill problems can be solved.

3. Writing code was never the whole job

This is what most “engineering is dead” posts miss.

Typing code is just one step. Here’s how a real feature gets built:

The green box is where AI shines. Boilerplate, small functions, quick tests. It’s genuinely fast there.

But look at everything else. Someone still has to:

• Figure out what the customer actually wants
• Decide how the system should be designed
• Catch the edge case the AI quietly skipped
• Fix production when it breaks at 2 AM

That someone is an engineer.

4. A tale of two developers

Imagine two developers joining the same company on the same day.

Developer A: “AI does it all”

Copies whatever AI gives. Closes tickets fast. Looks great for three months.

Then a payment bug appears. It only happens when two requests hit at the same millisecond. AI suggests five fixes. None work.

Developer A is stuck, because they never understood the code in the first place.

Developer B: “AI helps, I decide”

Uses AI every day too. But reads every line, asks questions, and pushes back.

Sees the same bug and thinks: “This looks like a race condition.” Adds a lock, writes a test, done.

Same tool. Very different result.

AI doesn’t replace engineers. It amplifies whatever is already inside them.

5. So what should you do?

No need for a dramatic career switch. Just get sharper at the basics.

1. Master the fundamentals. DSA, OS, networking, databases. This is what lets you judge if AI’s code is good or dangerous.
2. Build real projects. Pick things slightly too hard for you. Read other people’s code too.
3. Use AI, but stay the driver. Treat it like a fast junior teammate: helpful, often right, never accountable.
4. Learn system design early. It’s exactly where freshers can stand out.
5. Practice thinking out loud. Interviews now test how you reason, not just your final answer.

The bottom line

Software engineering isn’t dying.

It’s dropping its most boring, repetitive layer and asking more from the people who stay.

It happened with compilers. With the internet. With the cloud. It’s happening again.

The winners won’t be the fastest typists. They’ll be the ones who understand problems, think in systems, and use AI as a tool.

The door isn’t closing. It just has a new lock. And you can learn to open it.

Tools to help you prepare

Knowing what to learn is one thing. Having the right place to practise it is another. These three platforms map directly to the plan above: learn, track, and rehearse.

A quick note for transparency: I built these platforms. I’m sharing them because they were made for exactly the problem this article is about.

1. AlgorithmXlr8: learn system design and DSA the structured way

algorithmxlr8.io

A one-stop learning platform for engineers preparing for software engineering interviews.

• High Level Design: how real scalable systems are built, taught in an interview context with no skippable topics
• Low Level Design: class diagrams, relationships, design principles and API-level components
• System Design Scenarios: real cross-questioning of the kind that comes up in most interviews
• DSA patterns and core concepts, plus a weekly engineering newsletter with system design stories

2. CodEyes: all your engineering stats in one profile

codeyes.in

Your progress is usually scattered across half a dozen platforms. CodEyes brings it together.

• Connects LeetCode, Codeforces, CodeChef, GitHub, Medium and Substack in one free profile
• Shows total questions solved, active days, streaks, contest ratings and a submission heatmap
• Contest tracker and leaderboard to keep you consistent
• A clean public link you can add to your resume or share with recruiters

3. InterviewXlr8: your AI interviewer for every round

interviewxlr8.io

The best way to get better at interviews is to give more of them. InterviewXlr8 lets you do that without waiting for the real thing.

• An AI interviewer that talks to you, asks follow-up questions and scores you like a real panel
• Live evaluation of the key points you cover and how clearly you explain them
• Mock rounds for coding and DSA, system design and SQL
• Ideal for placements, job switches or your very first interview, starting at ₹199

Learn on AlgorithmXlr8. Track your growth on CodEyes. Rehearse on InterviewXlr8.

That combination still gets people hired, in the AI era or any other.

Remember this. Mark my words.

You will still need DSA. You will still need system design. You will still need every fundamental we have been learning all these years.

If this article helped, share it with someone who has been worrying about the future of tech. They will probably appreciate it.

Hi, I am Himanshu.

I worked as a Senior Software Engineer. Today I work as a Senior AI Engineer.

I learned AI engineering in 7 months. Since then I have built a lot of AI agents, and many of them now do real work for me every single day.

Right now I am working on something that would have sounded crazy to me a year ago. I am training my own model on a standalone server sitting in my home.

My first real AI project started with a simple question from my dad. ChatGPT gave him a confident but wrong answer about our electricity bill. So I built my first RAG system that could read our own documents and answer correctly. I wrote about it here.

Now I share what I learn with other engineers.

Almost every week I get a message on Instagram that looks like this.

“Bhaiya I have done a LangChain course. I made a chatbot. But I am getting rejected in every AI interview. What am I doing wrong?”

The person is usually not weak. Most of them are good developers. They work hard. They watch every new video.

So I ask them three small questions.

What does an embedding actually store?
Your chatbot has the right document. Why does it still give a wrong answer?
You changed your prompt. How do you know the new one is better?

Most of the time the reply is the same.

“I know how to use the tools. I don’t know what is happening inside.”

That line stayed with me. Because I made the same mistake when I started. I jumped to the shiny things first. I copied code that worked and felt good about it. Then the first time something broke I had no idea where to even look.

The problem was never hard work. The problem was the order.

When I sat down to build the AI Engineering track on AlgorithmXlr8 I spent most of my time on one question. What should a person learn first and what should come later?

This article is the answer. 20 steps in simple words. For every step I have added a lesson link so you can start today.

First, what does an AI engineer do?

An AI engineer does not invent new models. That is research work.

An AI engineer takes a model that already exists and builds a useful product with it. You connect it to data. You connect it to tools. You make sure it gives correct answers. You make it fast and cheap. Then you ship it.

Simple way to remember it. A researcher builds the engine. An AI engineer builds the car.

So you need two things. Good software skills and a clear idea of how models work. Here is the full path.

Phase 0: The basics

Step 1. DSA and system design

I know you want to start with AI. But most AI engineer interviews still have a coding round and a system design round. And every AI product is first a normal software product. It has APIs, a database and users who don’t like waiting.

If you already work as a developer just revise and move on. If you are in college please don’t skip this.

Read: DSA Patterns and High Level Design

Phase 1: Math and data

Step 2. Stats, probability and linear algebra

Don’t be scared of this. You only need the basics. What is a vector. What is a dot product. What does probability mean. That’s it. Embeddings and attention are built on these ideas.

Give it two or three weeks. Don’t sit on math for six months.

Lesson: Scalars, Vectors and Matrices

Step 3. NumPy and Pandas

Models work with numbers in arrays. Data comes in big tables. NumPy handles arrays. Pandas handles tables. You will use both every day.

Lesson: Introduction to NumPy

Step 4. Cleaning and plotting data

Real data is messy. Empty values. Repeated rows. Wrong formats. If you feed bad data to a model you get bad answers. Learn to clean data and draw simple charts so you can see what is going on.

Lesson: Introduction to Data Cleaning

Phase 2: Build and learn how models learn

Step 5. FastAPI

A model inside a notebook helps nobody. FastAPI lets you turn your code into an API that an app can call. Learn it early. After this every project you make can be used by real people.

Lesson: What is FastAPI?

Step 6. Machine learning basics

Regression. Decision trees. Clustering. Overfitting. These old ideas still matter. They teach you why models fail and how to test them. Many real problems are still solved with simple models.

Lesson: What is Machine Learning?

Step 7. Deep learning basics

Neural networks. How they learn. And then transformers, the idea behind every big AI model today. After this step words like tokens and context window will finally make sense.

Lesson: What is Deep Learning?

Step 8. PyTorch

Now write it yourself. Train one small model from start to end in PyTorch. Once you do this, AI stops feeling like magic.

Lesson: Introduction to PyTorch

Phase 3: Working with LLMs

This is where most people start. See how it is step 9 here. When you reach this point with strong basics you will learn it very fast.

Step 9. Prompting and model APIs

A good prompt is just clear instructions. Tell the model what to do. Give it the right information. Show an example. Ask for a fixed output format. Also learn how to call model APIs properly.

Lesson: What is Prompt Engineering?

Step 10. RAG and vector search

If you go deep on only one topic, pick this one. It comes up in almost every AI interview I hear about.

RAG means two things. First find the right information. Then give it to the model so it can answer. That’s all.

One thing I learned the hard way. When a RAG chatbot gives a wrong answer, the model is usually not the problem. The search gave it the wrong pages. Always check the search part first.

Lesson: What is RAG?

Step 11. Fine-tuning

Fine-tuning means training an existing model a little more on your own data. Learn it. But don’t use it first. Most problems get fixed with a better prompt or better search. Fine-tune only when nothing else works.

Lesson: What is Fine-Tuning?

Step 12. MCP

MCP is a standard way to connect an AI model to tools and data. Think of it like a USB port for AI. One plug that works with many tools. It is becoming a must-know topic.

Lesson: What is MCP?

Step 13. Hugging Face

Hugging Face is where open models and datasets live. When you want to run your own model instead of using an API, you come here.

Lesson: Introduction to Hugging Face

Phase 4: Agents

Step 14. Agents and tool calling

An agent is an AI model that works in a loop. It thinks. It uses a tool. It checks the result. Then it decides if it is done or needs one more round.

Also learn when not to use an agent. Many times a simple script is enough.

Lesson: What is an Agent?

Step 15. LangChain and other frameworks

Now is the right time for LangChain. You already know what it does behind the scenes. So when something breaks you will know how to fix it.

Lesson: What is Orchestration?

Step 16. Build your own projects

Watching is not learning. Building is. Make your own small chatbot client. Your own vector database. Your own RAG system. These projects teach more than any certificate and they look great on a resume.

Project: Build Your Own RAG System

Step 17. LangGraph

For bigger agents that need many steps, retries or a human to approve something in the middle. LangGraph lets you draw your agent like a flowchart and run it.

Lesson: What is LangGraph?

Want to go deeper on agents? There is a full separate agent course too. Start here: What Is an AI Agent? Full course: AI Agent Development

Phase 5: Production

This is the part that makes you an engineer and not just a demo builder.

Step 18. Deployment

A demo works for one person. A real product works for thousands of people at the same time without a huge bill. Learn how to serve models, cache answers and track cost.

Lesson: Batch Inference

Step 19. Evaluation

How do you know your AI is giving good answers? You test it. Make a set of questions with correct answers and check your system against it every time you change something.

Lesson: Why Evaluation Matters

Step 20. Security

People will try to trick your AI. They will try to make it leak data or do things it should not. When your AI can send emails or touch a database, security is a must.

Lesson: Authentication

What not to learn first

Don’t start with LangChain. Understand the basics first.

Don’t try to train your own big model. No company expects that from you.

Don’t study only math for months. Learn a little and start building.

Don’t fine-tune before fixing your search. It costs more and usually fixes nothing.

Don’t chase every new model launch. Names change every week. Basics don’t.

Don’t collect certificates. Build projects.

How long will it take?

If you give around two hours a day, this is a normal pace. It is very close to how I did it myself in 7 months.

Some people will be faster. Some will be slower. Both are fine. Going in the right direction matters more than going fast.

Last thing

Remember that message? “I know how to use the tools. I don’t know what is happening inside.”

Tools will change every year. New frameworks will come. New models will come. But if you know what is happening inside, you can learn any new tool in a weekend. That is what makes someone really good at AI engineering.

The full roadmap with every step is here: algorithmxlr8.io/ai/engineering/home. Every step has a lesson so you can try it first. The full AI agent course is here: AI Agent Development.

If this helped you, save it and share it with one friend who is stuck watching tutorials. And tell me in the comments which step you are on. I read every comment.

Himanshu

Let me be very honest with you from the start.

Six months back I had stopped doing DSA completely. My LeetCode streak was dead. My notebook of graph problems was lying somewhere under my bed. Why would I waste time on linked lists when Copilot and ChatGPT and Claude can write the full function in ten seconds?

Every second post on LinkedIn was saying the same thing. “DSA is useless now.” “Companies will stop asking it.” “Just learn prompting yaar.”

I agreed with all of it. I was shipping features faster than ever. My manager was happy. I felt like a 10x developer.

Then came that one Thursday night.

The night everything broke

I am Himanshu. I work as a backend developer at a small startup. We handle orders for local sellers.

That week I got a simple task. Find duplicate orders before sending them to the payment system. Same customer, same product, same amount within a few minutes means it is probably a duplicate.

I opened my AI tool and typed the requirement. Within seconds I had clean code. Proper variable names. Comments also. I tested it on 500 sample orders from staging. Worked perfectly. Raised the PR. Got approved. Deployed on Thursday evening.

At 2:47 AM my phone started ringing.

The order API was timing out. Sellers were complaining. Payments were stuck. My manager was on the call and his voice was not very friendly.

I opened the code again with half sleepy eyes. And there it was. Sitting quietly inside that beautiful AI code.

A loop inside a loop.

For every order it was checking every other order. On 500 rows that is around 2.5 lakh comparisons. Nothing. Your laptop does it before you blink.

But production had 2 lakh orders that day.

2 lakh multiplied by 2 lakh is 40 billion comparisons.

No server in this world is going to finish that before a seller in Indore loses his patience.

The red line is what AI gave me. The green line is what I should have asked for.

The fix took 10 minutes. Knowing the fix took 2 years.

I didn’t ask AI for help this time. I just knew.

Make a key from customer id plus product id plus amount. Put it in a HashSet. While going through the orders check if the key is already there. If yes it is a duplicate. If no add it and move ahead.

One loop. O(n). 2 lakh operations instead of 40 billion.

Deployed at 3:20 AM. API came back to normal in two minutes.

Sitting there at 3:30 AM with cold chai I realised something which changed my whole thinking.

AI didn’t make a mistake. AI gave me exactly what I asked for. I asked for code that finds duplicates. It found duplicates. It never knew my table would have 2 lakh rows. It never knew the API had a 30 second timeout. That context was in my head. Not in the prompt.

And the only reason I could fix it in ten minutes was those boring evenings in college where I solved “Two Sum” with a HashMap and felt like a genius.

What AI really can’t do (yet)

After that night I started noticing these gaps everywhere. Here are the ones I see almost every week.

1. AI doesn’t know your scale.

It writes code for the example you gave. Your production data is 1000 times bigger. Only you know that. And only DSA tells you what happens when n grows.

2. AI can’t judge its own output.

It will give you an O(n²) solution with the same confidence as an O(n) solution. Both look clean. Both pass small tests. If you can’t read complexity you can’t tell which one will kill your server.

3. AI doesn’t debug your 3 AM problem.

When things break in production you don’t have time to paste 15 files and explain everything. You need to look at code and feel where the problem is. That feeling comes from practice.

4. AI can’t sit in your interview.

Most product companies in India still do live DSA rounds. Many have moved to in person or proctored rounds because of AI cheating. A friend of mine got rejected from a good company last month. He could build full apps with AI. He couldn’t explain why he used a list instead of a set.

5. AI can’t defend your design in a meeting.

When your senior asks “why not a heap here” you can’t say “ChatGPT told me”. You need to know the tradeoff yourself.

The third box is where your salary comes from.

So is DSA still needed?

Yes. But not in the way we were taught.

You don’t need to mug up 500 LeetCode problems anymore. That era is going away. AI can recall syntax better than any of us.

What you need is the thinking behind DSA.

• Looking at code and knowing its time complexity in five seconds
• Knowing when to use a HashMap vs a Heap vs a Tree vs a Graph
• Smelling a nested loop on large data from far away
• Breaking a big messy problem into small pieces before you even open the AI chat

Think of it like this. AI is a very fast car. DSA is knowing how to drive. A Ferrari with a person who can’t drive is not fast. It is just dangerous.

My new routine

After that night I made a small change. Nothing crazy.

• 30 minutes daily. One or two problems. Only patterns. Sliding window, two pointers, hashing, BFS and DFS, heaps, DP basics.
• Every AI generated function gets one question from me. What is the time complexity and what happens at 1 lakh rows?
• Solve first, then check with AI. Not the other way around.

Within three months my code reviews became sharper. I caught two more O(n²) issues in other people’s PRs before they reached production. My manager noticed. That is the kind of thing that shows up in appraisals.

Final words

AI is doing 99% of the typing now. That is true and I am not fighting it. I use AI every single day.

But the remaining 1% is judgement. And judgement is the part they pay you for.

That 1% is what woke me up at 2:47 AM. And that 1% is what let me go back to sleep at 3:30.

So no bhai. DSA is not dead.

It just stopped being about writing code. Now it is about knowing when the code is wrong.

Where I practice now

After this story many friends asked me one thing. Bhai where do you practice? So I built two things for exactly this problem.

1. AlgorithmXlr8.io

This is everything I wish I had when I was preparing. DSA patterns explained with real interview context. High Level Design and Low Level Design without skippable topics. Real system design scenarios that come up in 90% of interviews. One subscription and everything is open. No hidden paywalls.

• Learn DSA by patterns, not by mugging 500 problems
• HLD and LLD in one place, built for interviews
• Scenario based cross questioning like a real interviewer
• Weekly engineering newsletter with system design stories

2. CodEyes.in

Once you start practising you want to see your growth. CodEyes connects LeetCode, Codeforces, CodeChef, GitHub, Medium and Substack into one profile. Your streak, your contest rating and your submission heatmap. All in one link.

• One public profile link you can put on your resume
• Track your daily streak and contest rating across platforms
• Contest tracker so you never miss a contest
• Get your coding profile roasted for honest feedback

Learn on AlgorithmXlr8. Track on CodEyes. That is the full loop.

If this hit home for you, give it a clap and share it with that one friend who says “DSA is useless now”. Tell me in the comments. Has AI code ever broken something for you in production?

When I started my career as a frontend developer I thought architecture was something only senior people talk about in long meetings. I used to think my job was to make the button blue and make the API call work. That is it.

Then one day I joined a project where a single React file had 3000 lines. Nobody knew where the state was coming from. A small change in the header was breaking the checkout page. That day I understood why architecture matters.

In this article I will explain every major frontend architecture pattern I have seen in real projects. I will keep it simple. I will tell you what the pattern is and when you should use it. I will also tell you when you should not use it because that part is equally important.

So grab your chai and let us start.

First what do we even mean by frontend architecture?

Frontend architecture is just the answer to three simple questions.

1. Where does my data live?
2. How does my data move from one place to another?
3. How is my code divided into files and folders?

Every pattern you will read below is one way of answering these three questions. Some patterns focus on data. Some focus on UI. Some focus on how the page reaches the browser. Once you see it like this the whole topic becomes much less scary.

I have divided the patterns into four groups.

• Data and state patterns like MVC, MVP, MVVM and Flux
• UI and component patterns like Atomic Design and Container Presentational
• Code organisation patterns like Feature Sliced Design, Clean Architecture and Monorepo
• Rendering and delivery patterns like SSR, SSG, Islands, Server Components and Micro Frontends

Part 1. Data and State Patterns

1. MVC (Model View Controller)

This is the grandfather of all patterns. It came from desktop apps long before the web was a thing.

The idea is to split your app into three parts.

• Model holds the data and business rules
• View shows the data to the user
• Controller listens to the user and tells the model what to change

The user clicks something. The controller catches that click and updates the model. The model then tells the view that something changed. The view redraws itself.

Old frameworks like Backbone.js and early AngularJS followed this pattern. Even today many backend frameworks like Spring MVC follow it.

When to use it. Small apps and server rendered apps where the flow is simple.

Where it hurts. In big frontend apps many views talk to many models. The arrows start going everywhere and you get what we call spaghetti. Debugging becomes a nightmare because you cannot tell who changed what.

2. MVP (Model View Presenter)

MVP is a small twist on MVC. Here the view becomes very dumb. It does not talk to the model at all.

• View only shows things and passes user events to the presenter
• Presenter holds all the logic and updates the view directly
• Model holds the data

The good thing about MVP is testing. Since the presenter has all the logic and no UI code you can test it very easily. This pattern was very popular in Android apps and in GWT based web apps.

When to use it. When you want logic that is fully separate from the UI so you can unit test it.

Where it hurts. You write a lot of extra code. Every view needs its own presenter and its own interface.

3. MVVM (Model View ViewModel)

MVVM is the pattern that made two way data binding famous.

• Model is your data coming from the server
• View is the HTML template
• ViewModel is a special object that holds the state of the view

The magic part is the binding. When the ViewModel changes the view updates on its own. When the user types in an input box the ViewModel updates on its own. You do not write any code to sync them.

Vue.js, Angular, Knockout and Svelte are all heavily inspired by this idea. If you have ever used v-model in Vue or ngModel in Angular then you have used MVVM.

When to use it. Form heavy apps like admin panels, dashboards and enterprise tools where a lot of inputs are directly linked to data.

Where it hurts. Two way binding is easy at first but in very large apps it becomes hard to track which change triggered which update. One small change can cause a chain reaction across the screen.

4. Flux and Redux (Unidirectional Data Flow)

Facebook faced exactly the problem I just mentioned. Their notification count was showing wrong numbers because too many things were updating too many other things. So they created Flux. Redux came later and made Flux simpler.

The rule is very strict. Data flows in only one direction.

1. The view dispatches an action. An action is just a plain object like { type: “ADD_TO_CART”, payload: item }.
2. The reducer receives the action and the current state. It returns a brand new state.
3. The store saves that new state.
4. Every component that subscribed to the store gets the new data and re renders.

What about API calls? Reducers must be pure functions so they cannot call APIs. That work goes into middleware. If you have used Redux Thunk or Redux Saga then you know what I am talking about. Thunk is simple and good for most cases. Saga uses generator functions and is great when you have complex flows like retry logic, cancelling requests or running tasks in parallel.

When to use it. Medium to large apps where many screens share the same data. Think ecommerce cart, user session or a live trading dashboard.

Where it hurts. Boilerplate. For a simple app it feels like writing ten files to toggle one checkbox. Redux Toolkit has fixed a lot of this pain so if you are still writing old style Redux please give RTK a try.

Today we also have lighter options like Zustand, Jotai and Recoil. They follow the same idea of a central store but with much less code. And for server data most teams now use React Query or SWR instead of keeping everything in Redux.

Part 2. UI and Component Patterns

5. Component Based Architecture

This is the foundation of almost every modern framework. React, Vue, Angular, Svelte and Solid all follow it.

The idea is simple. You build your UI as a tree of small independent pieces. Each piece has its own markup, its own style and its own logic. You combine small pieces to make bigger pieces. Just like Lego.

A good component follows a few rules.

• It does one job well
• It gets its data through props or inputs
• It does not reach out and touch other components directly
• It can be reused in another screen without changes

Honestly every other pattern in this article sits on top of this one. If you get components right half of your architecture problems are already solved.

6. Atomic Design

Brad Frost gave us this idea and it is borrowed from chemistry. Your UI is built in five levels.

• Atoms are the smallest things. A button. An input. A label. An icon.
• Molecules are small groups of atoms. A search box is an input plus a button.
• Organisms are bigger sections. A header has a logo, a nav menu and a search box.
• Templates are page layouts with empty slots.
• Pages are templates filled with real content.

This pattern is the backbone of most design systems. If your company has a shared UI library in Storybook then most likely it is organised like this.

When to use it. When you are building a design system or when many teams share the same UI components.

Where it hurts. People waste a lot of time arguing whether something is a molecule or an organism. My advice is do not be too strict. Use the levels as a guide and not as a law.

7. Container and Presentational Components

Dan Abramov made this pattern popular in the early React days. The idea is to split every feature into two types of components.

• Container components know how things work. They fetch data, manage state and handle events.
• Presentational components know how things look. They only receive props and render UI.

So you might have a UserListContainer that calls the API and a UserList that just shows the cards.

The best part is that your presentational components become super reusable and super easy to test.

A small update. After React Hooks came this pattern became less strict. Now we usually move the container logic into a custom hook like useUsers() and the component just calls that hook. The idea is the same. Only the shape has changed.

8. Compound Components and Render Props

These are smaller patterns but you will see them in every good component library.

Compound components let a parent share state with its children without passing props manually. Think of how a select box works in HTML.

<Tabs>
  <Tabs.List>
    <Tabs.Tab>Profile</Tabs.Tab>
    <Tabs.Tab>Settings</Tabs.Tab>
  </Tabs.List>
  <Tabs.Panel>Profile content</Tabs.Panel>
  <Tabs.Panel>Settings content</Tabs.Panel>
</Tabs>

The Tabs parent keeps track of the active tab and shares it through context. Radix UI and Headless UI use this pattern a lot.

Render props and headless components give you the logic and let you decide the UI. Libraries like TanStack Table and Downshift work this way. They handle sorting, filtering and keyboard support. You just write the markup.

Part 3. Code Organisation Patterns

9. Feature Sliced Design

Most of us start a project like this.

src/
  components/
  hooks/
  services/
  utils/

This is called organising by type. It works fine for small apps. But when your app grows the components folder has 200 files and you have no idea which file belongs to which feature.

Feature Sliced Design fixes this. It organises code by feature and by layer.

• app has global setup like providers, routing and styles
• pages are full screens
• widgets are big independent blocks on a page
• features are user actions like add to cart or login
• entities are business objects like user, product or order
• shared has reusable stuff like UI kit, helpers and API config

The golden rule is that a layer can only import from layers below it. A feature can use an entity. An entity can never use a feature. This one rule alone stops so much circular dependency mess.

When to use it. Medium to large apps with multiple developers.

Where it hurts. There is a learning curve. New developers need some time to understand where to put things.

10. Clean Architecture (Layered Architecture)

This idea comes from the backend world and Uncle Bob. But it works beautifully in the frontend too, especially in apps with heavy business logic.

• Domain layer has pure business rules. No React. No API. Just plain TypeScript. For example a function that calculates the final price after discount and tax.
• Application layer has use cases. These are your hooks or services that connect the UI with the domain.
• Infrastructure layer talks to the outside world. API clients, local storage, analytics.
• UI layer is your React or Vue components.

The main benefit is that your business rules do not depend on any framework. If tomorrow your company moves from React to something else your domain code stays exactly the same.

When to use it. Banking apps, insurance apps, trading platforms or anything where the business logic is complex and important.

Where it hurts. For a simple marketing site this is total overkill. Do not build a five storey building for a tea stall.

11. Event Driven Architecture (Pub Sub)

Sometimes two parts of your app need to talk but they do not know each other. Here an event bus helps.

One part publishes an event like “item added”. Any other part that cares about it can subscribe and react. The cart widget does not need to know that the header badge, the analytics tracker and the toast message exist.

You can build this with a tiny custom emitter, with the browser’s CustomEvent API or with libraries like mitt. It is also very common in micro frontends where different apps need to talk to each other.

When to use it. Loosely connected widgets, plugin systems and micro frontends.

Where it hurts. Too many events and you lose track of the flow. Please keep a list of all event names in one place. Your future self will thank you.

12. Monorepo Architecture

A monorepo is one Git repository that holds many apps and many shared packages.

For example your customer website, your admin panel and your mobile app can all live in one repo. They share the same UI library, the same utils and the same ESLint and TypeScript config.

Tools like Nx, Turborepo and pnpm workspaces make this easy. They are smart enough to only build and test the parts that actually changed.

When to use it. When you have multiple apps that share a lot of code.

Where it hurts. CI setup and access control get tricky. A very big monorepo also needs good tooling or builds become slow.

Part 4. Rendering and Delivery Patterns

This part is about how your HTML actually reaches the user’s browser. This decides your page speed and your SEO.

13. SPA vs MPA

Multi Page Application (MPA) is the classic web. Every click loads a new HTML page from the server. Old PHP sites, JSP apps and most WordPress sites work like this.

Single Page Application (SPA) loads one HTML page once. After that JavaScript handles everything. Clicking a link just swaps the content without a full reload. Apps built with Create React App or plain Vite React are SPAs.

SPAs feel smooth like a mobile app. But the first load can be slow and search engines may struggle with them. That is why the patterns below exist.

14. CSR, SSR, SSG and ISR

Client Side Rendering (CSR). The server sends an almost empty HTML file and a big JavaScript bundle. The browser runs the JS and builds the page. Good for dashboards behind login where SEO does not matter.

Server Side Rendering (SSR). The server builds the full HTML for every request and sends it. The user sees content quickly. Then JavaScript loads and makes it interactive. This step is called hydration. Good for pages that change often and need SEO like a product page or a news feed.

Static Site Generation (SSG). All HTML pages are built once at build time and served from a CDN. Super fast and super cheap. Good for blogs, docs and landing pages.

Incremental Static Regeneration (ISR). This is a mix of SSG and SSR. Pages are static but they rebuild in the background after a fixed time or when you trigger it. Good for an ecommerce site with thousands of products where prices change sometimes but not every second.

Next.js, Nuxt, Remix and SvelteKit let you use all of these in the same app. You can choose per page. This flexibility is the reason these meta frameworks became so popular.

15. Islands Architecture

Here is a question. Why should a blog page load JavaScript for the whole page when only the comment box needs it?

Islands Architecture answers this.

The page is mostly static HTML. Only a few small parts are interactive. These parts are called islands. Each island loads its own JavaScript independently. Everything else is plain HTML with zero JavaScript.

Astro made this pattern famous. Fresh and Eleventy with plugins also support it.

When to use it. Content heavy sites like blogs, marketing pages, docs and news sites.

Where it hurts. Not a good fit for apps where almost everything is interactive like a Figma clone or a chat app.

16. React Server Components

This is the newest big pattern and it changed how we think about React.

Now components are of two types.

• Server Components run only on the server. They can read the database directly. Their code is never sent to the browser. So your bundle size becomes smaller.
• Client Components run in the browser. You mark them with “use client” at the top. Only these can use useState, useEffect and event handlers.

Server components can render client components and pass props to them. So you keep the heavy data work on the server and send only small interactive pieces to the browser.

The Next.js App Router is built fully around this idea.

When to use it. New Next.js projects where performance and SEO matter.

Where it hurts. The mental model is new. Many developers get confused about what runs where. Some older libraries also do not work well inside server components yet.

17. Micro Frontends

Imagine a company like Flipkart or Amazon. Hundreds of developers work on one website. If everybody pushes code into one big frontend app then every release becomes a war.

Micro Frontends solve this by doing for the frontend what microservices did for the backend.

The website is split into smaller apps owned by different teams. One team owns product pages. Another owns the cart. Another owns payments. Each team can deploy on its own without waiting for others. In theory each team can even use a different framework.

A shell app (also called host or container) loads these micro frontends and handles common stuff like routing, login and layout.

Popular ways to build them.

• Module Federation in Webpack or Rspack. This is the most common choice today.
• Single SPA as a framework to mount multiple apps together.
• Web Components as a framework neutral wrapper.
• iframes which are old school but still used for strong isolation.

When to use it. Large organisations with many independent teams.

Where it hurts. It adds a lot of complexity. Shared dependencies, version mismatch, consistent styling and performance all become harder. For a team of five developers please do not do this. A well structured monolith is better.

18. Backend for Frontend (BFF)

This one sits between the frontend and the backend but frontend teams usually own it.

Different clients need different data. The mobile app wants a small response. The web app wants a richer one. Instead of making every client call five microservices and stitch the data you create a small server for each frontend. That server collects data from the services and returns exactly what the frontend needs.

You can build a BFF with Node.js, with Next.js API routes or with GraphQL.

When to use it. When you have many backend services and multiple types of clients.

Where it hurts. One more layer to build, deploy and monitor.

So which pattern should you choose?

This is the most important part so please read it slowly.

You never choose only one pattern. A real app is always a combination. Let me give you a real example from a typical ecommerce project.

• Next.js with SSR and ISR for product pages
• React Server Components for heavy listing pages
• Feature Sliced Design for the folder structure
• Atomic Design for the shared UI library
• Redux Toolkit or Zustand for the cart and user session
• React Query for server data
• A BFF layer to combine product, price and stock services
• A monorepo with Turborepo to share code with the admin panel

See how each pattern solves one specific problem?

Here is a quick cheat sheet I use.

• Small personal project. Component based architecture with simple hooks. Nothing more.
• Blog or marketing site. SSG or Islands with Astro.
• Admin dashboard behind login. SPA with CSR, React Query and maybe Zustand.
• Ecommerce or content platform. Next.js with SSR, ISR and Server Components.
• Complex business app like banking. Add Clean Architecture and Feature Sliced Design.
• Huge company with many teams. Monorepo first. Micro frontends only if teams really need independent deploys.

A few things I learned the hard way

Start simple. Do not add Redux, micro frontends and clean architecture on day one. Add a pattern only when you actually feel the pain it solves.

Consistency beats perfection. A team following an average pattern consistently will always do better than a team where everybody follows their own perfect pattern.

Write it down. Keep a small README or an ADR (Architecture Decision Record) that explains why you picked a pattern. Six months later nobody will remember.

Patterns are tools and not religion. Use what fits your problem. Leave what does not.

Final words

Frontend architecture is not about using fancy names in interviews. It is about making sure that six months from now you and your team can still change the code without fear.

If you understood the core ideas from this article you are already ahead of many developers. Next time you start a project just ask those three questions. Where does my data live? How does it move? How is my code divided? The right pattern will become clear on its own.

If this article helped you then please give it a clap and share it with your developer friends. And tell me in the comments which pattern you use in your current project. I read every comment.

Happy coding!

Before you go

If you are preparing for interviews or you just want to grow as an engineer then here are two platforms I built. I think both of them will help you.

1. AlgorithmXlr8.io

AlgorithmXlr8.io is a one stop platform to master software engineering interviews in a systematic way.

• System Design. High Level Design and Low Level Design built for interview context. There are also real scenario based system design questions that come up in almost eery interview.
• DSA the systematic way. Pattern based learning like sliding window and two pointers. You also get the DSA-31 sheet for interviews and the CF-18 sheet for competitive programming.
• Beyond DSA. Fix real production bugs in a codebase you have never seen. Live incidents and multi file repository problems right in your browser in Java, Python, Node.js or C++.

2. CodEyes.in

CodEyes.in puts all your coding stats in one profile. Connect LeetCode, Codeforces, CodeChef, GitHub, Medium and Substack and see your full progress in one place.

• One shareable profile link that you can put on your resume
• Total questions solved, contests, active days and streaks across all platforms
• A contest tracker so you never miss a contest
• A leaderboard to compare yourself with other coders

Do check out both and tell me in the comments what you think. Your feedback really helps me make them better.

Written with love by Himanshu Singour

If I have 10 microservices and one API Gateway, where should I validate the JWT?

Should I validate it only at the API Gateway?

Or should I validate it again inside every microservice?

And then another question comes:

If every service validates the JWT, does every service need the private key?

And finally:

What actually happens when the user logs out?

These questions look complicated in the beginning.

But once you understand what the JWT, private key, public key, Gateway and microservice are each responsible for, the architecture becomes surprisingly simple.

Let’s understand it from the beginning.

First, let’s imagine a real system

Suppose we are building an HR platform.

We have one API Gateway and 10 microservices:

                         Client
                            |
                            v
                       API Gateway
                            |
       +--------------------+--------------------+
       |         |          |         |          |
       v         v          v         v          v
    User     Employee    Company   Payroll    Leave
   Service    Service    Service   Service   Service
       +--------------------+--------------------+
       |         |          |         |          |
       v         v          v         v          v
 Attendance   Audit     Document   Report   Notification
  Service    Service    Service    Service     Service

Now we need authentication.

We don’t want every service to implement username/password login.

So we introduce an Authorization Server.

                  Authorization Server
                            |
                            v
                         Client
                            |
                            v
                       API Gateway
                            |
              +-------------+-------------+
              |             |             |
              v             v             v
          Service 1     Service 2     Service 3
              ...

The Authorization Server is responsible for issuing access tokens.

In our case, that access token is a JWT.

Step 1: User logs in

The user enters their username and password.

User
 |
 | username + password
 v
Authorization Server

The Authorization Server verifies the credentials.

If everything is correct, it creates an access token.

For example:

{
  "iss": "https://auth.example.com",
  "sub": "user-123",
  "aud": "hrmis-api",
  "scope": "employee.read employee.write",
  "exp": 1799999999
}

These claims tell us things like:

iss   → Who issued this token?
sub   → Who is the user?
aud   → Who is this token intended for?
scope → What is the token allowed to do?
exp   → When does it expire?

RFC 9068 defines a standardized profile for JWT-formatted OAuth 2.0 access tokens and describes important claims and validation expectations.

But there is one very important thing happening here.

The Authorization Server signs this JWT using its private key.

Private key and public key:

Let’s stop here because this is where many people get confused.

There are two keys:

Private Key 
Public Key 

The private key belongs to the Authorization Server.

It must remain secret.

The Authorization Server uses it to sign tokens.

                Authorization Server
                         |
                    PRIVATE KEY 
                         |
                         | Sign
                         v
                        JWT

The public key is used by other components to verify that signature.

Authorization Server
        |
        | Public Key
        v
     Gateway
        |
        +------> Microservice 1
        |
        +------> Microservice 2
        |
        +------> Microservice 3

The important rule is:

The private key signs. The public key verifies.

The private key does not travel with the request.

The JWT does.

What does the JWT actually contain?

A JWT normally has three parts:

HEADER.PAYLOAD.SIGNATURE

Something like:

eyJhbGciOiJSUzI1NiJ9
.
eyJzdWIiOiJ1c2VyLTEyMyJ9
.
ABC123...

The payload contains claims.

The signature proves that the token was signed by someone holding the private key corresponding to the public key used for verification.

One important point:

JWT is not encrypted by default.

The payload can generally be decoded.

So don’t think:

“Nobody can see what’s inside my JWT.”

The important security property here is usually the signature, not secrecy.

Never put sensitive secrets or passwords inside a normal JWT payload just because it is encoded.

Step 2: Client calls the API Gateway

The user now wants employee information.

The client sends:

GET /employees/123

Authorization: Bearer <JWT>

The request goes to:

Client
   |
   | JWT
   v
API Gateway

Now the Gateway becomes the first security boundary.

Step 3: Gateway gets the public key

The Gateway does not need the private key.

It needs the public key of the trusted Authorization Server.

In modern OAuth/OIDC systems, public signing keys are commonly exposed through a JWKS endpoint.

Conceptually:

Authorization Server
        |
        | Public Key
        v
API Gateway

The Gateway can cache these keys.

It doesn’t need to download the public key every time a request arrives.

Step 4: Gateway validates the JWT

Now the Gateway has:

JWT
+
Trusted Public Key

It verifies the JWT signature.

Think about it like this:

Authorization Server

PRIVATE KEY
     |
     | signs
     v
    JWT
     |
     | travels through network
     v
API Gateway
     |
     | PUBLIC KEY
     v
  Verify

If the signature is valid:

Token was signed by the trusted issuer

If somebody changed the token:

Signature verification fails

For example, imagine an attacker changes:

scope = employee.read

to:

scope = employee.delete

The signature no longer matches the modified content.

The Gateway rejects it.

Gateway does more than checking the signature

A valid signature alone isn’t enough.

The Gateway should validate the token according to the expected issuer, audience, time validity, signing algorithm and authorization requirements.

For example:

Signature       
Issuer          
Audience        
Expiration      
Not Before      
Algorithm       
Scope          

Imagine the token says:

iss = auth.example.com
aud = hrmis-api
scope = employee.read
exp = future

The Gateway asks:

Did my trusted Authorization Server issue this?
             ↓
            YES
Is this token meant for this API?
             ↓
            YES
      Has it expired?
             ↓
             NO
Is the signature valid?
             ↓
            YES
Does it have the required permission?
             ↓
            YES

Only then does the Gateway forward the request.

Microsoft’s API gateway guidance recommends gateway-level validation while also emphasizing validation at the backend API.

Step 5: Gateway sends the request to the microservice

Suppose the request is for Employee Service.

The Gateway forwards the request.

Importantly, the Gateway can forward the access token as well:

Client
  |
  | JWT
  v
API Gateway
  |
  | same JWT
  v
Employee Service

So Employee Service receives something like:

GET /employees/123

Authorization: Bearer <JWT>

What does not get forwarded?

Private Key

The Gateway doesn’t send the private key.

And normally it doesn’t need to send the public key with every request either.

The microservice can already obtain/trust the Authorization Server’s public keys.

What about additional headers?

Now, the Gateway can also add some additional headers before sending the request to the microservice. For example, it may add X-User-Id, X-Tenant-Id, or X-Organization-Id. These values can be taken from the already validated JWT.

For example, if the JWT contains the user, tenant, and organization information, the Gateway can send:

Authorization: Bearer <JWT>
X-User-Id: user-789
X-Tenant-Id: tenant-123
X-Organization-Id: org-456

This makes it easier for the microservice to understand which user and tenant the request belongs to.

But there is one important rule: the microservice should not blindly trust these headers if the client can send them directly. The Gateway should validate the JWT first and then create or overwrite these headers using trusted information from the token.

So the flow becomes:

Client
   ↓
JWT
   ↓
API Gateway
   ↓
Validate JWT
   ↓
Add User/Tenant/Organization headers
   ↓
Microservice

These headers are not a replacement for JWT validation. They are simply additional context that the Gateway passes to the microservice.

Step 6: Microservice validates the JWT again

Now comes the part that creates the most discussion.

The Gateway already validated the token.

So why does Employee Service validate it again?

Because the service should not blindly trust the Gateway.

Employee Service has its own security boundary.

It receives:

JWT
+
Trusted Public Key

and verifies it.

Employee Service
                        |
                  PUBLIC KEY 
                        |
                        v
                    Verify JWT
                        |
                +-------+-------+
                |               |
              Valid           Invalid
                |               |
                v               v
          Business Logic       401

This is defense in depth.

The Gateway protects the system at the edge.

The microservice protects itself.

Microsoft explicitly recommends backend validation even when a gateway has already validated the access token.

Why is this actually important?

Today your architecture might look like:

Client
  |
Gateway
  |
Service

But six months later, someone may add another path:

Internal Service
      |
      v
Employee Service

Or:

Batch Job
    |
    v
Employee Service

Or perhaps somebody accidentally exposes the service internally.

Now someone can bypass the Gateway:

Attacker
   |
   X
Gateway
   |
   X
Employee Service

If Employee Service says:

“I don’t need to authenticate. Gateway already did it.”

you have a problem.

But if Employee Service says:

“I will validate the token myself.”

then:

Attacker
   |
   v
Employee Service
   |
   | Invalid / missing JWT
   v
  401

That is why the second validation is valuable.

Does every microservice need its own private key?

No.

This is probably the most important thing to remember.

If the Authorization Server is issuing the user JWT, then the Authorization Server owns the signing private key.

You don’t need:

Service 1 → Private Key
Service 2 → Private Key
Service 3 → Private Key
...
Service 10 → Private Key

That would be unnecessary and dangerous if all those services were given the ability to sign the same kind of tokens.

Instead:

                Authorization Server
                         |
                   PRIVATE KEY 
                         |
                       Signs
                         |
                         v
                        JWT
                         |
                         v
                       Client
                         |
                         v
                    API Gateway
                         |
                    PUBLIC KEY 
                         |
                       Verify
                         |
              +----------+----------+
              |          |          |
              v          v          v
          Service 1  Service 2  Service 3
              |          |          |
          PUBLIC KEY  PUBLIC KEY  PUBLIC KEY
              |          |          |
            Verify     Verify     Verify

The services only need the public key for verification.

Can someone steal the public key?

Yes.

And that’s okay.

It’s public.

If someone gets your public key:

Public Key
    |
    +---- Can verify tokens
    |
    +---- Cannot create legitimate tokens

But if someone gets the private key:

Private Key
    |
    +---- Can sign tokens
    |
    +---- Can potentially create tokens that validators accept

That’s why the private key is the crown jewel.

It needs strong protection.

How do microservices get the public key?

You don’t necessarily hard-code a public key manually into every service.

A common approach is for the Authorization Server to publish its public keys through a JWKS endpoint.

Conceptually:

Authorization Server
        |
        | JWKS
        v
+-------------------+
| Public Keys       |
|                   |
| kid = key-1       |
| kid = key-2       |
+-------------------+
        |
        v
Gateway / Services

The services can discover the issuer’s keys and cache them.

This becomes especially useful when keys are rotated.

What happens during key rotation?

Suppose today the Authorization Server is using:

Private Key 1

and the corresponding public key is:

Public Key 1

Tomorrow you want to rotate the signing key.

You create:

Private Key 2
Public Key 2

The Authorization Server starts signing new tokens using Private Key 2.

The public keys can temporarily contain both keys:

Public Keys:

Key 1
Key 2

Why?

Because old tokens may still be valid.

So the Gateway and microservices can verify:

Old JWT → Public Key 1
New JWT → Public Key 2

Once all old tokens have expired and the old key is no longer needed, Key 1 can eventually be removed.

This is where the JWT kid header is useful: it helps a validator identify which published key should be used.

Now let’s talk about service-to-service calls

Suppose:

Client
   |
   | User JWT
   v
Gateway
   |
   v
Order Service
   |
   v
Payment Service

Now we have another question:

Should Order Service send the same JWT to Payment Service?

There isn’t one universal answer.

It depends on what identity and authorization model you want.

One approach is to propagate the user’s access token:

Client
   |
 User JWT
   v
Order Service
   |
 User JWT
   v
Payment Service

Payment Service then validates the token.

But you must make sure the token’s intended audience and permissions are appropriate.

Another approach is for Order Service to obtain a separate access token for calling Payment Service:

Order Service
      |
      | service identity
      v
Authorization Server
      |
      | new access token
      v
Payment Service

This gives you a clearer service-to-service trust boundary.

The important thing is not to blindly forward a user token everywhere without thinking about audience and permissions.

Authentication vs Authorization

Another simple but important distinction:

Authentication

Who are you?

Authorization

What are you allowed to do?

Suppose:

JWT valid

That only tells us that the token is acceptable according to our validation rules.

It doesn’t mean the user can do everything.

For example:

scope = employee.read

may allow:

GET /employees/123

But it may not allow:

DELETE /employees/123

because that could require:

employee.delete

So the flow becomes:

JWT
 ↓
Validate token
 ↓
Authenticate identity
 ↓
Check permission
 ↓
Authorize operation
 ↓
Business logic

This distinction is extremely important in microservices.

Now the big question: What happens during logout?

This is where JWT is different from a traditional server-side session.

With a traditional session, you might have:

Browser
   |
   | session ID
   v
Server
   |
   v
Session Store

When the user logs out:

Delete session

The server can immediately know:

This session no longer exists.

JWT access tokens are often designed differently.

The token is usually self-contained.

For example:

JWT
 |
 +-- user
 +-- issuer
 +-- audience
 +-- scope
 +-- expiration
 +-- signature

The server doesn’t necessarily maintain a database entry saying:

JWT-123 = logged-in

So you cannot always just “delete the JWT from the Authorization Server.”

Simple JWT logout

The simplest flow is:

User clicks Logout
        |
        v
Client deletes access token
        |
        v
       Done

Now the client no longer sends:

Authorization: Bearer <JWT>

So future requests fail because there is no access token.

But there is an important catch.

What if someone already copied the JWT?

Imagine:

10:00 AM
User logs in

Access Token:
Valid until 10:15 AM

At:

10:05 AM

the user logs out.

The client deletes the token.

But suppose an attacker copied the token at 10:04.

That copied token may still be cryptographically valid until 10:15 unless your architecture has a server-side revocation mechanism or some other way to reject it earlier.

This is one of the fundamental trade-offs of stateless access tokens.

That’s why access tokens are generally short-lived

Instead of:

Access Token
Valid for 30 days

you normally use a relatively short-lived access token.

Conceptually:

Login
  |
  +---- Access Token
  |
  +---- Refresh Token

The access token is used to access APIs.

The refresh token is used to obtain a new access token, according to the authorization server’s policy.

So when the access token expires:

Access Token
     |
     X
   expired

the client needs to obtain another one.

Logout with refresh tokens

A more complete logout can look like:

User
 |
 | Logout
 v
Client
 |
 +---- Delete Access Token
 |
 +---- Stop using Refresh Token
 |
 v
Authorization Server
 |
 +---- Revoke / invalidate refresh credential

The exact logout and revocation behavior depends on the authorization system you’re using.

The important idea is:

Deleting the access token from the client prevents the normal client from using it.

Revoking the refresh credential prevents the client from obtaining new access tokens through that credential.

And the old access token naturally becomes unusable when it expires.

So the complete architecture looks like this

Now let’s put everything together.

                         +-----------------------+
                         | Authorization Server  |
                         |                       |
                         | PRIVATE KEY           |
                         +-----------+-----------+
                                     |
                                     | Sign
                                     v
                                    JWT
                                     |
                                     v
                                  Client
                                     |
                                     | Bearer JWT
                                     v
                         +-----------------------+
                         |      API Gateway      |
                         |                       |
                         | PUBLIC KEY         |
                         | Validate JWT          |
                         +-----------+-----------+
                                     |
                              Valid token
                                     |
              +----------------------+----------------------+
              |                      |                      |
              v                      v                      v
       +-------------+       +-------------+       +-------------+
       | User        |       | Employee    |       | Payroll     |
       | Service     |       | Service     |       | Service     |
       |             |       |             |       |             |
       | PUBLIC KEY  |       | PUBLIC KEY  |       | PUBLIC KEY  |
       | Verify JWT  |       | Verify JWT  |       | Verify JWT  |
       +-------------+       +-------------+       +-------------+
              |                      |                      |
              +----------------------+----------------------+
                                     |
                              Other Services
                                     |
                              Verify JWT
                                     |
                                     v
                                  Database

The pattern continues for all 10 services.

The request lifecycle in one minute

Let’s make the whole thing extremely simple.

User logs in:

User
 ↓
Authorization Server
 ↓
JWT signed with PRIVATE KEY
 ↓
Client

Client calls the API:

Client
 ↓
JWT
 ↓
API Gateway

Gateway:

Gateway
 ↓
PUBLIC KEY
 ↓
Verify JWT
 ↓
Check issuer
 ↓
Check audience
 ↓
Check expiration
 ↓
Check permissions

If valid:

Gateway
 ↓
JWT
 ↓
Microservice

Microservice:

Microservice
 ↓
PUBLIC KEY
 ↓
Verify JWT again
 ↓
Check required permission
 ↓
Business logic
 ↓
Database

The private key never leaves the Authorization Server.

The four rules I would remember

If you forget everything else, remember these four things.

1. Authorization Server owns the private key

PRIVATE KEY 
      ↓
    SIGN
      ↓
     JWT

2. JWT travels with the request

Client
  ↓
Gateway
  ↓
Microservice

3. Gateway and protected services verify using the public key

PUBLIC KEY 
      ↓
   VERIFY
      ↓
     JWT

4. Logout is different from session logout

Logout
  ↓
Client deletes access token
  ↓
Refresh credential is revoked/inactivated when applicable
  ↓
Short-lived access token eventually expires

If you need immediate invalidation of an already-issued access token, you need an additional revocation/introspection or deny-list strategy; that is a deliberate trade-off because it makes the system less purely stateless.

The architecture I would actually keep in my head

Don’t think:

“JWT is just a token.”

Think about the complete chain:

             PRIVATE KEY
                   |
                   | Sign
                   ↓
                  JWT
                   |
                   | travels
                   ↓
                CLIENT
                   |
                   | JWT
                   ↓
             API GATEWAY
                   |
             PUBLIC KEY
                   |
                Verify
                   |
                   ↓
             MICRO SERVICE
                   |
             PUBLIC KEY
                   |
                Verify
                   |
                   ↓
             Authorization
                   |
                   ↓
              Business Logic
                   |
                   ↓
                Database

That’s the whole story.

The private key creates the trust.

The JWT carries the identity and permissions.

The public key verifies that trust.

The Gateway rejects bad requests early.

The microservice verifies the request again because it is its own security boundary.

And logout is handled differently from traditional server-side sessions because a JWT access token can remain cryptographically valid until it expires unless you introduce a mechanism for earlier revocation.

Once this mental model is clear, JWT in a 10-service architecture is not really complicated.

It is simply:

Issue → Sign → Send → Verify at Gateway → Forward → Verify at Service → Authorize → Execute.

Why I started reading the actual standards

While working on this, I had a lot of questions about what should actually happen in a microservices architecture. Instead of just following our old implementation, I wanted to see how this problem is handled in real systems.

So I started reading the actual standards and engineering documentation.

First, I read RFC 9068. It is an IETF standard for JWT access tokens. The important part for this discussion is that it explains how a resource server should validate a JWT. It talks about checking things like the issuer (iss), audience (aud), signature, and expiration (exp). It also explains how the Authorization Server can publish the keys that resource servers use to validate tokens.

Read RFC 9068 — JWT Access Token Profile

Then I looked at Microsoft’s API Gateway guidance to understand what changes when APIs are placed behind a Gateway. It helped me look at the Gateway as an additional security layer instead of assuming that the Gateway should become the only place responsible for security.

Read Microsoft’s API Gateway guidance

I also looked at Cloudflare’s documentation to see how a large production platform handles application authentication and tokens.

Read Cloudflare’s Application Token documentation

What I learned from this

The main lesson for me was simple:

Before building an important architecture, first check how the problem is solved by the standards and by companies that have already built systems at scale.

This doesn’t mean we should copy Microsoft, Cloudflare, AWS, or anyone else blindly. Our requirements may be different.

The idea is to understand why they are doing something, what problem they are solving, and then decide what makes sense for our own system.

So instead of:

Think → Code → Find problems → Redesign

I prefer:

Read the standard
       ↓
Study real-world implementations
       ↓
Understand why
       ↓
Design
       ↓
Then code

Sometimes reading the right RFC or engineering documentation for an hour can save days of implementing the wrong architecture.

It was around 2 AM when my phone rang.

I was half asleep, so for a few seconds I just looked at the screen, hoping whoever was calling would call back in the morning.

Then I saw the team name. I picked it up.

“Production mein issue hai. Payment requests fail ho rahi hain.”

Bas. Neend gayi.

I opened my laptop and joined the call. Everyone was already trying to figure things out. Someone was checking logs, someone was looking at the database, and someone was asking about the latest deployment. And honestly, my first thought wasn’t some amazing debugging strategy.

It was simply, “Yaar, ab kya hua?”

That’s the thing about production issues. When something breaks on your local machine, you have time. You can add logs, put breakpoints, restart the application, change things and try again.

Production is different.

There are real users on the other side. Someone is trying to make a payment. Someone is waiting for an order. Someone is staring at an error message. And while you’re trying to understand the problem, people are waiting for an answer.

That’s where I learned one of the most important things about production debugging:

Don’t panic. And don’t start fixing things before you understand what is actually broken.

My First Instinct Used to Be Wrong

Earlier, whenever I saw a production issue, I would immediately open the code.

API failing? Open the controller.

Then the service.

Then the repository.

Then the database query.

Ten minutes later, I would have twenty tabs open and still wouldn’t know what was happening.

The problem wasn’t that I couldn’t debug.

I was just starting from the wrong place.

Instead of asking “Where is the bug?”, I should have been asking “What exactly is happening?”

So that night, I started with the simplest thing: the numbers.

How many requests were failing?

When did they start failing?

Were all payments failing?

Or only some?

That immediately gave us an interesting clue.

Not every payment was failing.

Some were going through perfectly.

Now the problem wasn’t “payment is down.”

Something was failing under a particular condition.

And suddenly, the problem became much smaller.

Don’t Trust the First Explanation

During production incidents, someone will almost always say something like:

“Database down hai.”

“API broken hai.”

“Payment service is down.”

I’ve learned not to take these statements as facts.

Usually, they’re just someone’s observation.

If a payment fails, it doesn’t necessarily mean the payment service is broken. Maybe the database is fine. Maybe the API is fine. Maybe a third-party service is returning something unexpected.

So now, whenever I hear “X is broken”, my first reaction is:

“Okay, let’s verify that.”

That one habit can save a lot of time.

Start With the Timeline

The next thing I usually check is the timeline.

When did the problem actually start? And more importantly, what changed just before it started?

Was there a deployment? A configuration change? A database migration? A traffic spike? A change in another service?

Production systems have a lot of moving parts, and sometimes your code hasn’t changed at all.

Maybe another service was deployed.

Maybe traffic suddenly increased.

Maybe a scheduled job started behaving differently.

Maybe an external API started responding slowly.

That night, we noticed that the failures had started shortly after a deployment. Interesting. But I didn’t want to immediately say, “Deployment caused it.”

It was a clue, not a conclusion.

The Production Debugging Flow

This is roughly how I approach a production issue now. I start broad, collect evidence, and slowly narrow the problem down until I reach the actual failure point.

Follow One Failing Request

At this point, instead of looking at thousands of logs, I picked one failing request. I wanted to follow its entire journey.

The request reached our API. The business logic ran. The database responded normally. Then our service called another service. And that’s where things started looking strange.

This is where I usually step back and look at the bigger picture. A production issue rarely gives you the answer from one place.

I look at the timeline, logs, metrics and request trace together, then compare the evidence before deciding what the actual root cause is.

The downstream service wasn’t completely down. It was responding, but in one particular scenario, the response wasn’t what our application expected.

That changed everything.

We weren’t dealing with a completely broken application.

We had a specific failure happening between two services.

This is something production teaches you pretty quickly: your application doesn’t live alone. It depends on databases, queues, other services, external APIs and infrastructure.

Sometimes your code is perfectly fine.

Something around it isn’t.

Find One That Works

One of the simplest things I do during debugging is compare a failing request with a successful request.

Same API?

Same type of user?

Same data?

Same region?

Same request?

Same downstream response?

Usually, there is a difference somewhere.

Maybe one particular data combination is causing the issue.

Maybe only older records fail.

Maybe only a particular user flow triggers it.

The moment you find that difference, the problem becomes much easier.

Instead of saying:

“The payment system is broken.”

You can say:

“Payments fail when this specific condition occurs.”

That’s a much better problem to have.

Logs Should Tell You a Story

I used to think more logs meant easier debugging.

Not really.

I’ve seen systems where a single request generates hundreds of log lines. Everything is logged, but when production breaks, finding the useful information becomes harder.

What you actually want is a story.

Which request was this?

What operation was happening?

Which service handled it?

Which dependency was called?

What happened after that?

This is where correlation IDs are extremely useful.

If a request travels through multiple services, you should be able to follow that request across the system.

At 2 AM, you don’t want more information.

You want the right information.

Don’t Change Everything at Once

This is probably the easiest mistake to make when everyone is waiting for you.

You increase a timeout.

Restart the service.

Change some configuration.

Modify the query.

Deploy again.

And suddenly everything works.

Great.

But what actually fixed it?

You don’t know.

Maybe the restart helped. Maybe the configuration change helped. Maybe the external service recovered at the same time.

That’s why I try to make one meaningful change at a time.

Change something.

Observe.

Measure.

Then move forward.

Otherwise, you might fix the problem without understanding it.

And the next time it happens, you’re back at the beginning.

Sometimes Rollback Is the Right Fix

There is sometimes a strange ego around deployments.

Engineers don’t want to rollback because it feels like admitting that the deployment was wrong.

But production doesn’t care about your ego.

If a recent deployment is strongly connected to the incident and rollback is safe, rollback.

The goal during an incident is not to prove that your code is perfect.

The goal is to get users back to a stable system.

You can investigate the real root cause afterward.

Production first. Ego later.

The Hardest Part Is Staying Calm

Honestly, the technical problem isn’t always the hardest part.

The pressure is.

Someone asks, “Any update?”

You say you’re checking.

Five minutes later:

“Any update?”

Another team is waiting. Someone wants to know the impact. Meanwhile, you’re staring at the logs thinking, “I still don’t know what’s happening.”

I’ve been there.

And I’ve learned that not knowing the answer doesn’t mean you need to start moving faster.

Sometimes you need to stop for thirty seconds.

Ask yourself:

What do I know?

What don’t I know?

What have I already ruled out?

What’s the next thing I can check?

That’s enough.

You don’t need to solve the whole incident in your head.

You just need to find the next useful clue.

The Problem Usually Becomes Smaller

At 2 AM, the problem looked huge.

“Payment is failing in production.”

But after checking the metrics, looking at the timeline, following one request and comparing it with a successful request, the problem became much smaller.

It wasn’t the entire payment system.

It wasn’t the database.

It wasn’t even the whole API.

It was a specific interaction between services under a specific condition.

That’s how I think about debugging now.

You don’t magically find the answer.

You keep removing possibilities.

One by one.

Until the giant production problem becomes one service, one request, one dependency and one bug.

And that’s when debugging becomes much easier.

Fixing the Bug Isn’t the End

Once everything starts working again, it’s tempting to close the laptop and forget the whole thing.

But that’s actually when the important questions start.

Why did this happen?

Why didn’t we catch it earlier?

Why didn’t our monitoring detect it?

Could we have handled the failure better?

Do we need better validation?

Better logging?

A timeout?

A circuit breaker?

A test?

The goal isn’t just to fix today’s incident.

It’s to make sure the same problem doesn’t wake you up at 2 AM again.

What I Finally Learned

I used to think a good engineer was someone who could look at an error and immediately know the answer.

I don’t think that anymore.

The engineers I respect most aren’t the ones who know everything.

They’re the ones who stay calm when they don’t know.

They don’t guess.

They don’t randomly change five things.

They don’t assume the first error message is the root cause.

They simply keep asking better questions.

Did the request reach the service?

Did the database respond?

Did the downstream service respond?

When did the problem start?

What changed?

Why did this request fail while another one worked?

Slowly, the huge problem becomes smaller.

And eventually, you find the answer.

So the next time your phone rings at 2 AM and someone says, “Production mein issue hai,” don’t immediately start changing things.

Take a breath.

Understand what is actually happening.

Follow one failing request.

Find one that worked.

Compare them.

Reduce the possibilities.

Then fix the thing that is actually broken.

Because production debugging isn’t about being the smartest person in the room.

It’s about staying calm enough to figure out what the system is trying to tell you.

And honestly, that’s one of the most valuable engineering skills I’ve learned.

Before You Go

One more thing.

If you’re serious about becoming a better software engineer, I’m building something that might be useful for you.

Instead of putting everything into one huge learning platform, I’ve created focused learning paths for different stages of an engineer’s journey.

Master AI Engineering
Learn how to build AI-powered applications, understand AI systems, work with LLMs, agents, RAG, and take AI from an idea to something that actually works.

Master AI Engineering: https://algorithmxlr8.io/ai/engineering/home

Master DevOps Engineering
Understand the engineering behind deployments, containers, CI/CD, cloud infrastructure, monitoring, scalability, and running applications reliably in production.

Master DevOps Engineering: https://algorithmxlr8.io/devops/engineering/home

Master Software Engineer Interviews
DSA, LLD, HLD, System Design and the kind of problems you’re actually expected to solve in software engineering interviews.

Master Software Engineer Interviews: https://algorithmxlr8.io/

The goal isn’t just to help you clear an interview.

It’s to help you become the engineer who actually understands what’s happening behind the code, how systems work, and how to build things properly.

If that sounds like the kind of engineer you want to become, come join me on the journey.

Explore: https://algorithmxlr8.io/

I still remember the first time I opened a genuinely large codebase.

I had worked on plenty of projects before. I knew Java. I knew Spring Boot. I knew APIs, databases, queues, Docker, AWS, all the usual things.

So when someone said, “You’ll need to understand this repository before making the change,” I thought:

Okay. Give me a couple of hours.

Then I opened the repository.

There were hundreds of folders.

controller

service

repository

config

client

consumer

producer

handler

factory

strategy

processor

scheduler

utils

And then there were folders whose names made absolutely no sense.

I opened one class.

It called another class.

That class called another service.

That service called a client.

The client published an event.

The event was consumed somewhere else.

That consumer triggered another service.

That service updated the database.

And somewhere in the middle, there was a Redis cache.

I closed the file.

Opened another one.

Same story.

After an hour, I had read a lot of code.

But I understood nothing.

And that’s when I learned one of the most important lessons of working with large software systems:

You don’t understand a large codebase by reading more code. You understand it by building the right mental model.

That completely changed how I approach unfamiliar repositories.

The Biggest Mistake: Starting With the Code

When developers join a new project, the first instinct is usually:

“Let me start reading the code.”

That’s exactly what I used to do.

Open UserController.

Read 200 lines.

Open UserService.

Read 400 lines.

Open UserRepository.

Read 100 lines.

Then jump to PaymentService.

Then OrderService.

Then some random utility.

After three hours, you feel productive because you have seen thousands of lines.

But if someone asks:

“So how does an order actually get created?”

You have no idea.

That’s the trap.

A large codebase is not a book.

You don’t read it from page 1 to the last page.

A large codebase is more like a city.

If you enter a new city, you don’t walk into the first building and start studying its walls.

First, you look at the map.

You figure out:

Where is the airport?

Where is downtown?

Where are the major roads?

Where are the important neighborhoods?

Only then do you start exploring individual buildings.

A codebase works exactly the same way.

Step 1: Don’t Read the Code. Find the Business.

Before looking at classes, ask:

What does this system actually do?

Imagine you join an e-commerce company.

You are given a repository called:

commerce-platform

You could start with:

src/
 ├── controller/
 ├── service/
 ├── repository/
 ├── config/
 ├── consumer/
 ├── producer/
 └── client/

But instead, ask a completely different question:

What happens when a customer places an order?

Now you have a story.

Customer opens the application.

They add products to the cart.

They click Buy Now.

The backend receives the request.

An order is created.

Payment is initiated.

Inventory is reserved.

The customer receives confirmation.

That’s already more useful than reading 500 classes.

Because now you’re not trying to understand the entire system.

You’re trying to understand one journey through the system.

And that journey becomes your entry point.

Step 2: Find the Entry Point

Every important operation has somewhere it enters the system.

For an HTTP application, it might be:

POST /orders

Search for it.

Maybe you find:

@PostMapping("/orders")
public OrderResponse createOrder(
        @RequestBody CreateOrderRequest request) {
return orderService.createOrder(request);
}

Perfect.

You now have your first door into the system.

Don’t immediately understand every line.

Just follow the path.

Controller
    ↓
Service
    ↓
Repository
    ↓
Database

Maybe the real system is more complicated:

Controller
    ↓
OrderService
    ↓
InventoryService
    ↓
PaymentService
    ↓
EventPublisher
    ↓
Kafka
    ↓
OrderConsumer
    ↓
NotificationService

Now something interesting happens.

You are no longer looking at classes.

You’re looking at a story.

And stories are much easier for humans to remember.

Step 3: Trace One Request End-to-End

This is probably the most powerful technique I’ve learned.

Pick one important operation.

For example:

“Create Order.”

Then trace it from beginning to end.

Write it down.

Literally.

POST /order
↓
OrderController
        ↓
OrderService.createOrder()
        ↓
InventoryService.reserve()
        ↓
PaymentService.charge()
        ↓
OrderRepository.save()
        ↓
Kafka → OrderCreatedEvent
        ↓
NotificationConsumer
        ↓
EmailService

Suddenly the giant repository doesn’t look so scary anymore.

You have discovered one path through the forest.

Now do the same for:

Cancel Order

DELETE /orders/{id}
↓
OrderController
        ↓
OrderService.cancel()
        ↓
PaymentService.refund()
        ↓
InventoryService.release()
        ↓
OrderRepository.update()
        ↓
OrderCancelledEvent

Now you understand two important business flows.

And something magical starts happening.

The same classes appear again.

You begin recognizing them.

“Oh, I’ve already seen OrderService.”

“I’ve already seen PaymentService.”

“So this event is also consumed by NotificationService.”

That’s how a large codebase slowly becomes familiar.

Step 4: Build Your Own Map

One mistake I see engineers make is trying to remember everything in their head.

Don’t.

Create a map.

It can be something as simple as:

                     ┌──────────────┐
                     │   Client     │
                     └──────┬───────┘
                            ↓
                     ┌──────────────┐
                     │ Controller   │
                     └──────┬───────┘
                            ↓
                     ┌──────────────┐
                     │   Service    │
                     └───┬──────┬───┘
                         ↓      ↓
                  ┌─────────┐ ┌─────────┐
                  │  DB     │ │ Payment │
                  └─────────┘ └────┬────┘
                                   ↓
                                Kafka
                                   ↓
                              Consumers

It doesn’t need to be beautiful.

It needs to be useful.

Personally, I like writing three things for every unfamiliar system:

1. What comes in?

HTTP
Kafka
Scheduler
External API

2. What happens in the middle?

Validation
Business logic
Database
Cache
External services
Events

3. What goes out?

HTTP response
Kafka event
Email
Database update
External API call

Once you can answer those three questions, the system becomes much easier to navigate.

Step 5: Understand the Data Before the Classes

Here’s another mistake I made early in my career.

I spent hours understanding services.

But I didn’t understand the data.

That’s backwards.

Suppose you’re working on a payment system.

Before understanding PaymentService.java, find out:

What is a Payment?

Maybe the database looks something like:

Payment
id
orderId
userId
amount
currency
status
transactionId
createdAt
updatedAt

Now the code starts making sense.

You see:

payment.setStatus(PaymentStatus.SUCCESS);

You know why it exists.

You see:

paymentRepository.findByOrderId(orderId);

You understand what relationship is being used.

You see:

transactionId

And you immediately think:

“This probably connects our payment record with the external payment provider.”

Without understanding the data, code is just syntax.

With the data, code starts telling a story.

Step 6: Find the Database Tables

Whenever I enter a new backend project, one of the first things I want to understand is:

What are the important entities?

For example:

User
Order
Product
Payment
Inventory
Shipment

Then ask:

User
  ↓
Order
  ↓
Payment
  ↓
Shipment

Maybe:

Order
 ├── userId
 ├── paymentId
 └── shipmentId

Now you have another mental model.

You understand not only what the code does, but also what the system is storing.

And this becomes extremely useful when debugging.

Because many production bugs eventually become:

“Something went wrong between these two pieces of data.”

Step 7: Don’t Ignore Configuration

This one looks boring.

It isn’t.

I’ve seen engineers spend hours trying to understand application behavior while completely ignoring:

application.yml
application.properties
.env
Dockerfile
docker-compose.yml

Configuration often tells you more about a system than the Java classes.

Look for:

Database
Redis
Kafka
S3
AWS
External APIs
Feature flags
Timeouts
Retries
Thread pools
Connection pools

Suppose you find:

payment:
  timeout: 3000
kafka:
  retries: 3
redis:
  ttl: 3600

Now you already know something about the architecture.

The system talks to a payment provider.

It uses Kafka.

It uses Redis.

The payment call has a timeout.

Kafka retries failures.

Redis data expires after an hour.

You just learned a lot without reading hundreds of classes.

Step 8: Find the External Systems

Large systems almost never live alone.

They talk to other systems.

Your codebase might interact with:

Payment Gateway
Kafka
Redis
PostgreSQL
MongoDB
S3
Elasticsearch
Notification Service
Identity Service

Find those integrations.

Search for things like:

RestTemplate
WebClient
FeignClient
KafkaTemplate
RedisTemplate
S3Client
MongoRepository
JpaRepository

Then ask:

Why does this system depend on that system?

That’s important.

Don’t just memorize:

“We use Kafka.”

Understand:

“We use Kafka because order processing doesn’t need to wait for notification processing.”

Now you’ve understood the reason, not just the technology.

And reasons are easier to remember.

Step 9: Use Git Like a Detective

This is one of the most underrated techniques.

When you don’t understand why some weird code exists, don’t stare at it for two hours.

Check Git history.

For example:

git log

Or:

git blame PaymentService.java

You might discover:

Added retry logic after payment provider timeout issue

Suddenly that strange-looking code makes sense.

Maybe you find:

if (attempt > 2) {
    throw new PaymentException();
}

At first you think:

“Why only two retries?”

Git history might tell you:

“Because the payment provider starts rate-limiting requests after three attempts.”

Boom.

The code wasn’t random.

There was a production incident behind it.

This is why mature codebases sometimes look messy.

You’re not just reading software.

You’re reading the history of decisions.

Step 10: Read Tests Before Implementation

This changed my life.

Suppose you find:

OrderService.createOrder()

You could open the implementation.

Or you could first search:

OrderServiceTest

Tests often tell you what the business actually expects.

For example:

shouldNotCreateOrderWhenInventoryUnavailable()
shouldRefundPaymentWhenOrderCancellationFails()
shouldRetryPaymentWhenProviderTimesOut()
shouldNotDuplicateOrderForSameIdempotencyKey()

Look at those test names.

You just discovered important business rules.

And you didn’t need to read 500 lines of implementation.

Tests are often the closest thing to executable documentation.

Step 11: Learn the “Happy Path” First

Don’t start with exceptions.

Don’t start with every edge case.

Don’t start with the most complicated class.

First understand:

What happens when everything goes right?

For an order:

Request
 ↓
Validate
 ↓
Create Order
 ↓
Reserve Inventory
 ↓
Charge Payment
 ↓
Save Order
 ↓
Publish Event
 ↓
Send Confirmation

That’s your happy path.

Once you understand that, start asking:

What happens if payment fails?

Payment fails
      ↓
Retry
      ↓
Still fails
      ↓
Release inventory
      ↓
Mark order FAILED
      ↓
Return error

Then:

What happens if Kafka is down?

Then:

What happens if the request is sent twice?

Then:

What happens if the database succeeds but event publishing fails?

This is how you move from basic understanding to real engineering understanding.

Step 12: Look for the Weird Parts

Once you’ve understood the normal flow, start looking for things that make you say:

“Why the hell are they doing this?”

Those places are gold.

Maybe you find:

Thread.sleep(500);

Why?

Maybe you find:

cache.put(key, value, 300);

Why 300?

Maybe you find:

if (retryCount < 3)

Why three?

Maybe you find:

@Transactional

Why is the transaction boundary here?

Maybe you find:

eventPublisher.publish(...)

inside a database transaction.

Now you have interesting questions.

And these questions often lead you toward the most important architectural decisions in the system.

Step 13: Don’t Try to Understand Every Class

This is probably the most important thing in this entire article.

You don’t need to understand 100% of the codebase.

You need to understand the 20% that matters for your task.

Imagine you receive this ticket:

“Fix duplicate payments when the client retries the request.”

You don’t need to understand:

UserProfileService
RecommendationEngine
SearchService
NotificationService
AnalyticsService
ReportingService

You need to find:

Payment API
      ↓
Payment Service
      ↓
Payment Provider
      ↓
Database

Then ask:

Where is the request ID?

Where is idempotency handled?

Where is the payment persisted?

What happens when the same request comes twice?

Your understanding should be task-driven.

Not repository-driven.

A Real Example

Let’s say you join a company and receive this bug:

“Customers are sometimes charged twice when they click Pay multiple times.”

You open the repository.

You don’t start reading everything.

You start with:

POST /payments

You find:

PaymentController
       ↓
PaymentService
       ↓
PaymentGateway
       ↓
PaymentRepository

Then you ask:

What happens when the same request arrives twice?

You find:

public PaymentResponse pay(PaymentRequest request) {
paymentGateway.charge(
        request.getAmount()
    );
    Payment payment = new Payment();
    payment.setOrderId(request.getOrderId());
    paymentRepository.save(payment);
    return PaymentResponse.success();
}

And suddenly you see the problem.

The system charges first.

Then saves the payment.

There is no idempotency check.

So:

Request #1
    ↓
Charge ₹1000
    ↓
Save payment

Then the user retries:

Request #2
    ↓
Charge ₹1000 AGAIN
    ↓
Save another payment

The customer loses ₹2000.

You didn’t understand the entire repository.

You didn’t need to.

You understood the payment journey.

And that’s enough to solve the problem.

The 30-Minute Rule

When I enter an unfamiliar codebase, I now give myself a rule:

Don’t try to become an expert in the first 30 minutes.

The goal of the first 30 minutes is only to answer:

What does this system do?
Where does a request enter?
What are the major services?
Where is the database?
What external systems exist?
Where are the important business flows?
What part is relevant to my task?

That’s it.

If you can answer those questions, you’ve already won.

The “Breadcrumb” Technique

Here’s something I use constantly.

When you find an important method, don’t read everything around it.

Follow the breadcrumbs.

Suppose:

orderService.createOrder()

calls:

inventoryService.reserve()

Follow that.

Then:

paymentService.charge()

Follow that.

Then:

eventPublisher.publish()

Follow that.

Then:

OrderCreatedEvent

Search where it’s consumed.

Maybe you discover:

OrderCreatedEvent
        ↓
InventoryConsumer
        ↓
AnalyticsConsumer
        ↓
NotificationConsumer

One search leads to another.

That’s how you navigate a large repository.

Not randomly.

Breadcrumb by breadcrumb.

Ask “Why?” Five Times

Sometimes understanding code requires more than knowing what it does.

You need to understand why it exists.

For example:

Why are we using Redis?

Because database queries are slow.

Why are database queries slow?

Because this endpoint gets huge traffic.

Why does it get huge traffic?

Because it’s called every time the user opens the dashboard.

Why don’t we calculate the data once?

Because the data changes frequently.

Now you understand something much deeper:

Redis isn’t there because:

“Redis is cool.”

It’s there because of a specific performance requirement.

That’s the difference between knowing a system and understanding a system.

Eventually, the Codebase Starts Talking to You

This is the beautiful part.

At first:

OrderService
PaymentService
InventoryService
KafkaConsumer
RedisConfig

look like random names.

After a few days, they become familiar.

You see:

OrderCreatedEvent

and immediately think:

“Okay, something happened after an order was created.”

You see:

@KafkaListener

and think:

“This isn’t part of the synchronous request. Something is happening asynchronously.”

You see:

@Transactional

and think:

“Okay, these database operations probably need to succeed or fail together.”

You see:

@Cacheable

and think:

“This data is probably expensive to calculate or fetch.”

The code stops looking like thousands of unrelated lines.

It starts looking like a system.

My Exact Process Today

If you give me a repository I’ve never seen before, I don’t randomly open files anymore.

I usually go in this order:

1. README
      ↓
2. Project structure
      ↓
3. Application entry point
      ↓
4. Configuration
      ↓
5. Database/entities
      ↓
6. API endpoints
      ↓
7. One important business flow
      ↓
8. External integrations
      ↓
9. Events / queues
      ↓
10. Tests
      ↓
11. Git history
      ↓
12. Task-specific code

And while doing this, I keep one document open.

I call it:

“My Mental Model.”

Inside it, I keep only:

System purpose
Major components
Important APIs
Important database entities
External dependencies
Important events
Main business flows
Things I don't understand yet

That last section is extremely important.

Because instead of pretending I understand something, I write:

TODO:
Why do we publish OrderCreated twice?
TODO:
Why is Redis used here?
TODO:
Why does payment retry three times?
TODO:
Why is this transaction boundary here?

Now I have questions to investigate.

That’s much better than having confusion floating around in my head.

The biggest shift happens when you stop asking:

“How can I understand this entire codebase?”

and start asking:

“What story is this code trying to tell me?”

Because every large codebase has a story.

A request comes in.

Something validates it.

Some business decision happens.

Data changes.

Maybe another service gets called.

Maybe an event is published.

Maybe another system reacts.

Maybe the user gets a response.

That’s the story.

Your job as an engineer isn’t to memorize every class.

Your job is to reconstruct that story.

Once you know the story, the classes become characters.

The APIs become entry points.

The database becomes the memory.

The queues become the communication system.

The external services become the outside world.

The logs become the clues.

And Git history becomes the backstory.

Suddenly, the repository that looked like a monster yesterday starts looking like something you can actually reason about.

And that’s when you know you’ve crossed the line from:

“I am reading this code.”

to:

“I understand this system.”

That is the real skill.

Not knowing every file.

Not memorizing every class.

Not reading 10,000 lines a day.

It’s knowing where to look, what to follow, what questions to ask, and how to turn thousands of lines of code into one simple story.

One Last Thing

And one more thing I want to say.

Nothing is actually that complex.

Most of the time, our mind makes it complex before the problem even becomes complex. We see a large codebase, a new technology, system design, AI, distributed systems, or an unfamiliar architecture, and immediately think, “This is too difficult.”

But it isn’t.

You just need to make your mind more flexible, lean, and adaptable.

Don’t try to understand everything at once. Don’t try to memorize everything. Just follow what you are reading, understand one thing at a time, connect it with the previous thing, and keep moving.

Eventually, the things that looked confusing in the beginning start becoming obvious.

And if you are preparing for an AI Engineer or Software Engineer role, don’t try to learn everything randomly. Start exploring the right concepts, understand how they connect, and follow a systematic learning path.

Once your learning becomes systematic, your confidence naturally starts growing.

You don’t need to become a genius.

You just need to keep learning, keep exploring, and keep making your mind more adaptable.

That’s how complicated systems slowly become simple.

And if you want to take that journey further:

If you want to master your Software Engineering interviews: https://algorithmxlr8.io/

If you want to master your AI Engineering interviews: https://algorithmxlr8.io/

Keep learning.

Keep exploring.

And most importantly, don’t let your mind convince you that something is difficult before you have actually tried to understand it.

I still remember when I first started getting serious about AI.

At that time, AI was everywhere. Every second person was talking about ChatGPT, LLMs, RAG, agents and the next big AI framework.

I was already working as a software engineer, so I initially thought this would be easy for me. I knew how to build APIs, work with databases, write backend services and think about scalable systems. I thought I just needed to learn how to call an LLM.

I was wrong.

The first few days were actually exciting. I started with Python because most of the AI ecosystem was built around it. I already knew programming, so Python itself wasn’t the difficult part.

But then I started seeing things like embeddings, transformers, vector databases, RAG, LangChain, LangGraph, agents, memory, tool calling and MCP. Every time I understood one thing, I discovered three more things.

That was probably the first problem I faced.

I wasn’t struggling because AI was impossible to learn. I was struggling because I didn’t know what I should learn first.

So instead of randomly jumping between YouTube videos, blogs and new AI frameworks, I decided to step back and look at AI Engineering from an engineer’s perspective.

I asked myself a simple question:

If I had to build a real AI product from scratch, what would I actually need to know?

That question changed everything.

I Started With Things I Already Knew

I didn’t start my AI journey by trying to understand every mathematical detail behind neural networks. I started from the engineering side.

I went back to Python, because I wanted to become comfortable building AI applications with it. Then I made sure I was comfortable with things that are easy to ignore when you’re excited about AI: Git, APIs, HTTP, JSON, databases, SQL, asynchronous programming, Docker and basic cloud concepts.

At first, these topics didn’t feel like AI.

I remember thinking, “Why am I learning Git and Docker again? I came here to learn AI.”

But later I understood why.

Suppose you build an AI application that works perfectly on your laptop. Now imagine someone else needs to run it. Your application needs an API. It needs configuration. It needs a database. It needs deployment. It needs logging. It needs error handling. It needs version control.

The LLM is only one part of the application.

That realization became very important for me.

I stopped thinking about AI as a separate world and started looking at it as another type of software system.

Then I Went Back to Machine Learning

After getting comfortable with the engineering foundations, I started going deeper into Machine Learning.

I didn’t want to become a research scientist. My goal was to understand what was happening underneath the tools I was using.

I learned about data, features, training, validation, models, overfitting and evaluation. Then I moved towards Deep Learning and started understanding neural networks and how models learn patterns from data.

This was interesting because I had spent years writing software where I explicitly told the computer what to do.

With traditional programming, I could write:

“If this happens, do this.”

Machine Learning felt different.

Instead of manually writing every rule, I was giving the system data and allowing a model to learn patterns.

That difference was important to understand before jumping into modern LLM applications.

Then I Found Transformers

The next big step for me was understanding Transformers.

Before that, LLMs felt almost magical.

You type a question.

The model understands it.

It generates an answer.

But when I started learning about tokens, embeddings, attention and transformers, the magic started becoming engineering.

I still didn’t understand every mathematical detail, and I didn’t need to.

What I wanted was a mental model.

I wanted to understand what happens between:

Text → Model → Output

That foundation made it much easier for me to understand modern LLMs.

Then I Started Building With LLMs

Once I understood the basics, I started using LLM APIs.

This part was fun.

You could write a small amount of code and suddenly have an application that could summarize text, answer questions, extract structured information or generate content.

But after building a few simple applications, I hit another problem.

The model didn’t know my data.

I could ask it general questions, but what if I wanted it to answer questions about my own documents?

What if those documents were private?

What if the information changed every week?

What if I had thousands of documents?

Putting everything inside the prompt obviously wasn’t going to work.

That was when I discovered RAG.

RAG Was a Big Turning Point

RAG completely changed how I thought about AI applications.

Instead of:

Question → LLM → Answer

the system could become:

Question → Retrieve relevant information → LLM → Answer

That sounds simple when you write it like that.

But when I actually started building one, I realized how many engineering decisions were hiding underneath.

How should I split a document?

How large should a chunk be?

Should I keep metadata?

How should I create embeddings?

Where should I store them?

How many documents should I retrieve?

What if the retrieved documents are wrong?

What if the answer isn’t present in the knowledge base?

What if the document changes?

Suddenly my simple RAG application wasn’t so simple anymore.

And honestly, this is where I started learning much faster.

Because I wasn’t learning RAG from a definition anymore.

I was learning it because my own application was giving me bad answers.

I Started Understanding Embeddings and Vector Databases

To make RAG work properly, I needed to understand embeddings.

At first, the idea felt strange.

How can a piece of text become numbers?

And how can those numbers help me find similar information?

I started experimenting with embeddings and vector databases.

Then I understood the basic idea: instead of searching only for exact words, we could represent information in a form that allowed us to find semantically similar content.

That opened another area of learning.

Vector search.

Similarity.

Metadata filtering.

Indexing.

Retrieval.

Hybrid search.

And once again, I realized that the AI application was not just an LLM call.

There was an entire retrieval system around it.

Then I Started Building AI APIs

At this point I wanted to move beyond notebooks and small experiments.

I wanted to build proper AI backend services.

That’s where FastAPI became useful.

I started thinking about an AI application like any other backend system.

There is an API.

There is validation.

There are services.

There is a database.

There are external dependencies.

There are failures.

There are timeouts.

There are retries.

There are logs.

There are users.

The difference is that somewhere inside the system, there is an LLM making probabilistic decisions.

That difference creates a completely new set of engineering challenges.

For example, in a normal API, I can usually predict what a function will return.

With an LLM, the output can change.

It can be correct.

It can be incomplete.

It can misunderstand the request.

It can hallucinate.

It can return something in the wrong format.

So I started thinking about validation and reliability much more seriously.

Then Agents Started Getting Interesting

After building RAG systems, I started asking another question.

What if the AI could actually do something instead of just answering?

What if I gave it a calculator?

What if I gave it a database?

What if it could call an API?

What if it could search something?

What if it could decide which tool to use?

That led me into AI Agents and tool calling.

The first time I built a simple tool-calling workflow, it felt very different from a chatbot.

The model wasn’t just generating text.

It was deciding what action should happen next.

But again, the moment I started building more complicated workflows, things became messy.

What happens when the tool fails?

What happens when the model calls the wrong tool?

What happens when the agent keeps repeating the same action?

Where do we store state?

How do we retry?

When should a human take over?

Those questions pushed me deeper into agent engineering.

LangGraph Changed My Mental Model

When I started learning LangGraph, something clicked.

Instead of thinking about an agent as some magical autonomous AI, I could think about it as a workflow.

There is state.

There are nodes.

There are decisions.

There are edges.

There can be loops.

There can be retries.

There can be human intervention.

That was much easier for me to reason about as a software engineer.

I started building workflows where one step would retrieve information, another would call a tool, another would validate the result and another would decide what should happen next.

The more I built, the more I realized that a good AI agent is not about giving the model unlimited freedom.

It’s about designing the right boundaries around it.

Then I Started Thinking About Memory

One problem became obvious after building conversational systems.

The AI forgets.

You can have a long conversation with a system, start a new session and suddenly it knows nothing.

That made me curious about AI memory.

What should an AI remember?

Should it remember everything?

Probably not.

Should it remember user preferences?

Maybe.

Should it remember previous tasks?

Sometimes.

Should memories expire?

Probably.

Where should memories be stored?

How should they be retrieved?

These questions made me realize that memory is not just “store the chat history.”

It is another engineering problem.

Then Came MCP

As I continued exploring AI agents and tools, I came across MCP.

What interested me wasn’t just the protocol itself.

It was the idea behind it.

AI systems need to interact with external tools and data.

Instead of every AI application creating completely different integrations, there could be a standardized way for models and applications to discover and use capabilities.

That made me think about AI applications differently again.

The future AI application isn’t just a chatbot sitting inside a box.

It can interact with databases, APIs, files, developer tools and other systems.

The model becomes one part of a much larger ecosystem.

Then Reality Hit: AI Can Be Wrong

This was probably one of the most important lessons I learned.

A demo can look amazing.

A production system is different.

You can build a RAG system that works perfectly on five documents.

Then you put 50,000 documents into it and everything changes.

You can build an agent that works perfectly ten times.

Then it gets a slightly different request and enters a loop.

You can write the perfect prompt.

Then the model gives you an unexpected answer.

That forced me to learn about AI evaluation.

I started thinking about questions like:

How do I know my retrieval is good?

How do I know the answer is correct?

How do I detect hallucinations?

How do I compare two versions of a prompt?

How do I know whether a new model is actually better?

Traditional unit tests aren’t enough for every AI problem.

AI systems need their own evaluation strategy.

That was another major shift in my thinking.

Then I Started Thinking About Production

Once you build enough AI applications, you eventually stop asking:

“Can I make this work?”

and start asking:

“Can I make this reliable?”

That’s a completely different question.

Now you start thinking about latency.

Token costs.

Caching.

Retries.

Timeouts.

Rate limits.

Streaming.

Logging.

Monitoring.

Tracing.

Security.

Authentication.

Deployment.

Scaling.

Model selection.

Fallbacks.

This is where my software engineering background became extremely useful.

Because AI may be new, but production engineering problems are not.

An AI application still needs good architecture.

It still needs good APIs.

It still needs proper databases.

It still needs observability.

It still needs security.

It still needs testing.

It still needs people who understand what happens when something goes wrong at 2 AM.

I Also Made Plenty of Mistakes

One thing I don’t want to hide is that I wasted a lot of time.

I jumped between frameworks.

I watched tutorials without building anything.

I sometimes learned a tool before understanding the problem it was solving.

I built small demos that looked impressive for five minutes but taught me very little.

There were also times when I thought I understood something because I could explain the definition.

Then I tried building it.

And got stuck.

That was a good lesson.

There is a huge difference between knowing:

“A vector database stores embeddings.”

and actually debugging why your retrieval system is returning irrelevant documents.

There is a difference between knowing:

“Agents can call tools.”

and debugging an agent that keeps calling the same tool again and again.

There is a difference between knowing:

“RAG reduces hallucinations.”

and actually discovering that bad retrieval can make the final answer even worse.

Building exposes those gaps very quickly.

Eventually I Stopped Learning AI as Separate Topics

This was probably the biggest change in my learning.

Earlier, I saw everything separately.

Python was one thing.

Machine Learning was another.

LLMs were another.

RAG was another.

Agents were another.

Vector databases were another.

FastAPI was another.

MCP was another.

Now I see them as pieces of one system.

A user sends a request.

The API receives it.

The application decides what needs to happen.

Maybe it retrieves information.

Maybe it calls a tool.

Maybe it uses memory.

Maybe an agent workflow is required.

The model generates a response.

The response gets validated.

The system records what happened.

Then we evaluate whether the system actually did a good job.

Suddenly all those individual topics started making sense together.

What Actually Helped Me Learn

If I had to choose one thing that helped me the most, it wouldn’t be a course or a particular framework.

It would be building things.

Whenever I learned something, I tried to build something small around it.

Learned RAG?

Build one.

Learned tool calling?

Build one.

Learned agents?

Build one.

Learned memory?

Build one.

Learned MCP?

Build one.

Learned evaluation?

Add evaluation to an existing project.

The project didn’t need to be huge.

Sometimes a small working project taught me more than spending an entire weekend watching tutorials.

The pattern became very simple:

Learn → Build → Break → Debug → Understand → Build again.

That’s how the knowledge started sticking.

I Also Started Explaining What I Learned

Another thing that helped me was writing about these concepts.

When you explain something to another engineer, you quickly discover what you don’t understand.

You think you understand RAG.

Then someone asks:

“Why this chunk size?”

And you realize you never really thought about it.

You think you understand agents.

Then someone asks:

“What happens when the tool fails?”

And suddenly you have another rabbit hole to explore.

Writing and teaching forced me to go one level deeper.

That’s also one of the reasons I started organizing these topics on AlgorithmXlr8.

I didn’t want AI Engineering to feel like a collection of random technologies.

I wanted to create a path where someone could start from the fundamentals and gradually reach real AI systems.

My Biggest Lesson

Looking back, I don’t think I learned AI Engineering by following one perfect roadmap.

I learned it by repeatedly getting stuck.

I learned Python because I needed it to build something.

I learned RAG because my LLM didn’t know my data.

I learned vector databases because I needed better retrieval.

I learned agents because I wanted the AI to take actions.

I learned LangGraph because agent workflows became difficult to manage.

I learned memory because conversations needed context.

I learned MCP because AI systems needed better access to tools.

I learned evaluation because “it seems to work” wasn’t good enough.

And I learned production engineering because eventually every demo needs to survive outside your laptop.

That’s what made AI Engineering interesting to me.

It isn’t just about AI.

It is about bringing everything together.

Software Engineering.

Data.

Machine Learning.

LLMs.

Backend Engineering.

Systems.

Infrastructure.

And a lot of experimentation.

If I Were Starting Again

If I were starting AI Engineering from zero today, I wouldn’t try to learn everything at once.

I’d first get comfortable with Python, Git, APIs, databases and basic software engineering.

Then I’d learn the foundations of Machine Learning and Deep Learning.

Then I’d understand LLMs and Transformers.

Then I’d build a RAG system.

Then I’d learn embeddings, vector databases and retrieval properly.

Then I’d build AI APIs with FastAPI.

Then I’d move into tool calling and AI Agents.

After that I’d learn LangGraph, state and workflows.

Then memory and MCP.

Then I’d spend serious time on evaluation, guardrails, reliability and production AI.

But I wouldn’t spend months learning each topic before building.

I’d learn enough.

Then build.

Then let the problems tell me what I need to learn next.

The Journey Isn’t Finished

Even after learning all of this, I don’t consider myself “done” with AI Engineering.

That’s probably the biggest difference between learning a technology and becoming an engineer.

There is always another problem.

A better retrieval strategy.

A better model.

A cheaper inference setup.

A more reliable agent.

A better evaluation method.

A new protocol.

A new architecture.

A new production problem.

And that’s okay.

I don’t think the goal is to finish AI Engineering.

The goal is to become good enough at engineering that when a new AI technology appears, you can understand where it fits, why it exists and when you should actually use it.

That’s the mindset I’m trying to build.

Don’t chase every new model.

Don’t learn every framework just because it’s trending.

Don’t build another chatbot just to say you built an AI project.

Understand the fundamentals.

Build real things.

Break them.

Debug them.

Measure them.

And keep going.

That’s how I learned AI Engineering.

And honestly, I’m still learning.

Want to Start Your AI Engineering Journey?

If you want to start learning AI Engineering and follow the same kind of path I followed, I’ve put the complete learning journey on my platform, AlgorithmXlr8.io

I’ve tried to structure it around the same question I had when I started: what should I learn first, what should I learn next, and how do all these pieces actually connect?

You can start with the fundamentals and gradually move towards Machine Learning, LLMs, RAG, AI Agents, workflows, memory, MCP and the other concepts required to build real AI systems.

If you’re also trying to figure out where to start with AI Engineering, you can start here:

https://algorithmxlr8.io

I’ve learned these concepts by building, breaking, debugging and going back to the fundamentals. I’ve tried to put that same approach into the platform so you don’t have to spend months jumping randomly between different resources.

If you’re starting your AI Engineering journey, you can start here too.

Last Sunday, I was sitting at home with my laptop.

My father walked in and asked,

Beta, what exactly do you build all day?

I smiled.

I said,

AI.

He looked confused.

Then he asked another question.

If AI is so intelligent, can it answer questions about our family’s documents?

I confidently opened ChatGPT.

I uploaded nothing.

Then I asked,

“What is my electricity bill for last month?”

The AI gave a beautiful answer.

It was also completely wrong.

My father laughed.

“So this intelligent AI doesn’t even know our own documents?”

That one sentence stayed in my head.

The Real Problem

Most people think an AI knows everything.

It doesn’t.

An LLM is like a student who studied millions of books before the exam.

But once the exam starts…

The books are taken away.

Now the student has to answer only from memory.

If you ask,

“Who won the Cricket World Cup 2011?”

Easy.

If you ask,

“What’s written on page 18 of my company’s HR policy?”

It has no idea.

Sometimes it says,

“I don’t know.”

Sometimes…

It confidently makes things up.

That’s called a hallucination. RAG was created to reduce those unsupported answers by grounding responses in external information.

Then I Thought…

What if the student was allowed to open the library before answering?

Not the whole library.

Just the few books related to the question.

Now imagine the process.

You ask,

“How many casual leaves do employees get?”

Instead of guessing…

Someone first walks into the library.

Searches the HR policy.

Finds the correct page.

Brings it back.

Only then does the student answer.

That’s exactly what RAG does.

A Simple Real-Life Example

Imagine your mother keeps every recipe in a notebook.

One day you ask,

“How do we make paneer butter masala?”

You don’t remember.

So you open the notebook.

Find the recipe.

Read it.

Then cook.

You didn’t magically know the recipe.

You retrieved it first.

That’s Retrieval.

Then you used that information to create the answer.

That’s Generation.

Together…

Retrieval-Augmented Generation.

How I Built It

I didn’t start with AI.

I started with documents.

I collected PDFs.

Company policies.

Technical documentation.

Product manuals.

Articles.

Then I broke every document into smaller pieces.

Because finding one paragraph is much easier than searching a 500-page PDF.

Next…

Every small paragraph became a numerical representation called an embedding.

Think of it like giving every paragraph its own GPS coordinates.

Similar ideas end up close together.

Different ideas stay far apart.

These embeddings were stored inside a vector database.

Now my documents became searchable by meaning instead of exact words. This semantic-search pattern is one of the core ideas behind modern RAG systems.

What Happens When Someone Asks a Question?

Suppose someone types,

“How many sick leaves can I take?”

The system doesn’t send that question directly to the LLM.

Instead…

The question is converted into an embedding.

The vector database searches for paragraphs with similar meaning.

It finds the most relevant chunks.

Those chunks are sent to the LLM.

The LLM reads them.

Then answers using only that information.

Not memory.

Evidence.

The Biggest Difference

Without RAG: Question → LLM → Guess

With RAG: Question → Search Documents → Retrieve Information → LLM → Accurate Answer

One extra step.

A huge difference.

The Funny Part

After building it…

I went back to my father.

This time he asked,

“What’s written in our electricity bill?”

The AI searched the uploaded bill.

Read the exact amount.

Answered correctly.

My father smiled.

“Now this feels intelligent.”

That was the moment I understood.

RAG doesn’t make an AI smarter.

It gives the AI access to the right information before it speaks.

Final Thought

When people hear “RAG,” they often imagine a complicated AI architecture.

But at its heart, it’s surprisingly simple.

Think of three roles:

• The Library → Your documents.
• The Librarian → Finds the right pages.
• The Teacher → Reads those pages and explains them in simple language.

That’s all a RAG system really is. (https://algorithmxlr8.io/ai/engineering/home/rag-vector-search/rag-fundamentals/what-is-rag)

And once you understand it this way, building one feels much less intimidating.

Want to Learn AI Engineering Step by Step?

Programming, Math & Data Foundations
│
├── Statistics & Probability
├── NumPy & Pandas
└── Data Cleaning & Visualization
│
Machine Learning & Deep Learning
│
├── Machine Learning Fundamentals
├── Deep Learning Fundamentals
└── PyTorch
│
LLM Engineering & Applications
│
├── Prompt Engineering
├── RAG & Vector Search
├── Fine-Tuning
├── MCP
└── Hugging Face
│
AI Agents & Orchestration
│
├── AI Agents & Tool Calling
└── LangChain & LangGraph
│
Deployment, Safety & Production
│
├── LLMOps
├── AI Safety & Evaluation
└── Security

Explore the complete at: https://algorithmxlr8.io/

Everyone talks about resigning. Very few people talk about the preparation that happens months before that decision.

The Thought Stayed in My Mind for a Long Time

I still remember the first time I seriously thought about leaving my 9–5 job.

It wasn’t because I had a bad manager.

It wasn’t because I hated my work.

It wasn’t even because I wanted to become an entrepreneur overnight.

The thought came from something much simpler.

Every evening after work, I would open my laptop again. Not because someone asked me to, but because I genuinely wanted to build something of my own.

Some days it was a small backend project.

Some days it was a DSA platform.

Sometimes I would just spend two hours reading about distributed systems or improving my engineering skills.

I started noticing something.

No matter how tired I was after office hours, I still found myself opening my laptop again.

That’s when I realized this wasn’t just a hobby anymore.

It was becoming something much bigger.

But even then, I never thought, “I’ll resign next month.”

Instead, I asked myself a different question.

“What needs to happen before I can even think about leaving?”

Looking back, that single question probably saved me from making a very emotional decision.

Watching People Quit Made Me Realize Something

Around the same time, I started seeing a lot of posts on LinkedIn and Twitter.

Someone would announce,

“Today is my last working day.”

Another person would post a picture of their resignation letter.

A few weeks later they would announce their startup.

It looked exciting.

For a few days, I also felt like maybe I should just do the same.

But social media only shows the final chapter.

Nobody posts about the months of uncertainty before that.

Nobody talks about wondering whether they’ll have enough money six months later.

Nobody talks about the nights when they question whether they’re making the biggest mistake of their career.

The more I thought about it, the more I realized something.

I wasn’t interested in quitting my job.

I was interested in building a life where leaving my job became a natural next step.

Those are two completely different things.

I Made One Rule for Myself

That weekend, I opened my notebook and wrote down one rule.

“Don’t resign because you’re frustrated. Resign only when you’re prepared.”

It sounds simple.

But it changed the way I looked at everything.

Whenever I felt like quitting after a stressful day at work, I would read that line again.

Frustration lasts for a few hours.

A resignation lasts much longer.

I promised myself that I would never make a career decision based on one bad week.

If I ever left, it would be because I had spent months preparing for it.

Not because I had a bad meeting on Monday morning.

My Evenings Started Looking Different

Earlier, once work was over, I would relax, watch random videos, scroll through social media, and call it a day.

Slowly, that changed.

I gave myself a small target.

Just two hours.

No unrealistic schedules.

No “I’ll study eight hours after office.”

That never worked.

Some evenings I worked on a side project.

Some evenings I learned AWS.

Some days I practiced DSA.

Other days I read about System Design or tried to understand a technology I had been avoiding.

There were many nights when I didn’t feel like doing anything.

Office had already drained my energy.

But I made a promise to myself.

Even if I wasn’t productive for two hours, I would at least sit in front of my laptop.

Some days those two hours became twenty minutes.

Some days they became four hours.

The important part wasn’t the duration.

It was showing up consistently.

I Stopped Waiting for the Perfect Idea

One mistake I made in the beginning was thinking I needed an amazing startup idea before I started building.

So I kept waiting.

Every week I thought,

“Maybe I’ll get a better idea next month.”

That month never came.

Eventually, I stopped chasing ideas.

Instead, I started solving problems I personally cared about.

If a tool didn’t exist, I built it.

If I found learning difficult, I created notes.

If I wanted a better way to study DSA and System Design, I started working on it little by little.

None of those projects were perfect.

Some never even got completed.

But every project taught me something.

How to deploy applications.

How to work with cloud services.

How to design better APIs.

How to fix production bugs.

How to deal with users.

More importantly, they taught me that building consistently matters far more than waiting for the perfect opportunity.

Money Was the Conversation Nobody Wanted to Have

For a long time, I ignored the financial side of leaving a job.

I only thought about passion.

Reality doesn’t work like that.

Rent doesn’t stop because you’re following your dream.

Bills don’t disappear.

Responsibilities don’t disappear.

I realized that if I wanted the freedom to make bold career decisions, I first needed financial stability.

So instead of rushing, I started saving.

Not because I expected to fail.

Because I wanted peace of mind.

Knowing that I could survive for several months without depending on my next salary completely changed the way I looked at risk.

Confidence doesn’t only come from skills.

Sometimes it comes from knowing you have enough time to recover if things don’t go according to plan.

The Biggest Lesson I Learned

Today, whenever someone asks me,

“How do I prepare before leaving my 9–5 job?”

I don’t tell them to resign.

I tell them to prepare until resigning feels obvious.

Build something while you’re still employed.

Learn skills that increase your value.

Save money.

Create habits that prove you can stay disciplined without someone managing your time.

If you can’t stay consistent for two hours after office, quitting your job won’t magically make you disciplined.

Freedom is amazing.

But freedom without discipline quickly turns into procrastination.

Looking Back

I’m glad I didn’t leave my job the first time I felt frustrated.

If I had, it would’ve been an emotional decision.

Instead, I spent months preparing quietly.

Nobody noticed those evenings.

Nobody saw the weekends I spent learning instead of going out.

Nobody celebrated the small milestones.

But those small efforts slowly built something much bigger than I had imagined.

Looking back now, I don’t think resigning was the hardest part.

Preparing for it was.

And that’s exactly why the transition felt less like jumping into the unknown and more like taking the next logical step.

If you’re thinking about switching from your 9–5, don’t ask yourself, “When should I resign?”

Ask yourself, “What can I start building today so that when the day comes, leaving feels like a decision not a gamble?”

That one question changed everything for me.

Maybe it’ll do the same for you.

If You’re Serious About Making the Switch

If you’ve read this far, chances are you’re thinking about something bigger than just changing jobs.

Maybe you want to become a better Software Engineer.

Maybe you’re preparing for AI Engineering roles.

Maybe you’re aiming for DevOps, SRE, or Backend Engineering interviews.

Whatever your goal is, one thing is true having a structured learning path makes a huge difference.

One of the biggest mistakes I made early in my career was learning random topics without any direction. I’d jump from one YouTube video to another, bookmark dozens of articles, and buy courses I never finished.

Progress became much faster once I started following a clear roadmap instead of learning whatever looked interesting that day.

That’s exactly why I built AlgorithmXlr8.

It isn’t just another collection of videos or interview questions. It’s a structured platform designed to help engineers master Software Engineering, AI Engineering, DevOps, DSA, System Design, and other interview-focused skills through a step-by-step learning path.

Everything is organized in the order you should actually learn it, so you always know what to study next instead of wondering where to begin.

If you’re serious about switching from your 9–5 job, growing as an engineer, or preparing for your next interview, I think you’ll find it genuinely useful.

You can explore it here: https://algorithmxlr8.io