What does it mean?

You tap an app and see a screen. But behind that screen, your phone and the company's computers are talking to each other.

Let's take a streaming app. You open it because you want to watch a movie.

How does it work?

1. Your phone starts the app. The code and data it is using need memory, called RAM.
2. The app may immediately show saved content, such as its logo or an old list of movies.
3. To get new information, it needs to contact a server.
4. It finds the server's address using DNS.
5. It makes a secure connection and asks, “Give me the home page information.”
6. The server finds the information and sends it back.
7. The app displays the movie list. Images and videos may come from separate delivery servers.

An app does not have to become completely useless without internet. Downloads, saved pages, or other offline features may still work.

What is DNS?

DNS means Domain Name System. Think of it like your phone's contact list. You remember a friend's name; your phone finds the number. Similarly, you remember example.com; DNS helps find its IP address.

An IP address is a network address used to reach a destination. IPv4 and IPv6 are two address formats.

Real-world use: Every time your browser needs to connect to a website by name, it needs the right address, often from a saved DNS answer.

Remember: DNS finds an address. It does not fetch your movie or carry your API request.

HLD means High-Level Design. LLD means Low-Level Design.

Imagine you are building a house.

First, you decide where the kitchen, bedrooms, and bathrooms will go. That is the big plan. Later, you decide how the kitchen cupboards, pipes, and wiring will work. That is the detailed plan.

Software works in a similar way.

Example: a train-booking app

HLD includes login, train search, seat booking, payment, and notification services.

LLD for booking includes a Booking class, a Seat class, and methods such as reserveSeat() and cancelBooking(). It also defines rules such as “a confirmed seat cannot be sold to another person for the same journey segment.”

Where is it used?

Use HLD to explain an application's overall structure. Use LLD when turning one part of that structure into code.

Remember: HLD describes the whole system. LLD explains its parts in detail.

What is scaling?

Scaling means changing your system's capacity so it can handle more work.

Imagine one cook can prepare 20 meals per hour. Now 100 customers arrive. You have two choices: give that cook better equipment, or bring in more cooks.

When would you use them?

A small application may first need a stronger server. This is often easier to manage.

A busy application may need several servers sharing the requests. A load balancer can send requests to those servers.

What are the problems?

Vertical scaling has a limit. You cannot keep adding power to one machine forever. If it is your only server and it fails, the application may stop.

Horizontal scaling gives you more machines to manage. They must agree about shared information, such as who is logged in and which seats are booked.

Remember: Vertical = more power in one machine. Horizontal = more machines.

What is it?

A load balancer shares incoming traffic across several servers.

Imagine a restaurant with five waiters. If every customer calls the first waiter, that person becomes overloaded while the others stand around. A manager can send customers to different waiters. A load balancer does a similar job for servers.

How does it work?

1. A request reaches the load balancer.
2. It chooses a suitable working server.
3. It sends the request there.
4. The server handles the request and returns a response.

It can also check which servers are healthy and avoid a server that has stopped working.

Real-world use: During a big sale, an online store runs many app instances. The load balancer spreads requests across them.

Simple ways to choose a server

Remember: A load balancer distributes capacity. If every server is overloaded, it cannot magically create more capacity.

What is it?

A CDN keeps copies of content in different locations so users can download it from a suitable nearby location.

Imagine a company has one warehouse far away. Every delivery takes a long time. It opens smaller warehouses near customers and keeps popular items there. Delivery becomes faster.

A CDN does something similar with images, files, and video parts.

How does it work?

1. You request an image.
2. A CDN edge server checks whether it has a usable copy.
3. If it has one, it sends it immediately. This is a cache hit.
4. If not, it gets the image from the original source. This is a cache miss.
5. It may keep a copy for the next person.

The original source is called the origin. An edge server is a delivery server closer to users in the network.

Real-world use: A course website can use a CDN for thumbnails and lesson videos. Its main server does not have to send every video byte to every student.

What is the catch?

A saved copy can become old. If you change an image, you need rules for replacing or expiring old copies. Private content also needs access control.

Remember: A CDN reduces the distance and repeated work needed to deliver content.

What is a proxy?

A proxy is a middleman that receives a request and passes it along.

The important question is: whose side is it working for?

Forward proxy example

Your college wants to block access to certain websites. Your request goes through its proxy. The proxy checks the rules and either forwards the request or blocks it.

Reverse proxy example

Your app has three backend servers. Users contact one public address. The reverse proxy receives requests and forwards them to the right backend.

A reverse proxy can handle routing, load balancing, caching, HTTPS connections, and compression.

Where are they used?

Forward proxies are useful for controlling outbound traffic. Reverse proxies are useful for managing incoming traffic to applications.

Remember: Forward proxy represents clients. Reverse proxy represents servers.

What problem do they solve?

Suppose you send a password across a network. You do not want someone watching that network to read it or secretly change the message.

HTTPS protects HTTP communication using TLS. People still commonly say “SSL certificate,” but modern connections use TLS.

What is a certificate?

Think of it as a checked identity document for a domain and its public key. A trusted organization called a Certificate Authority, or CA, signs it. Examples include Let's Encrypt and DigiCert.

How does it work, simply?

1. Your browser connects to the website.
2. The website presents its certificate and proves it controls the required private key.
3. The browser checks whether the certificate is valid for that domain and trusted.
4. The two sides establish keys used to protect their messages.
5. Your request and response travel with encryption and protection against changes.

Real-world use: Login pages, online shopping, and private APIs.

Remember: HTTPS protects the connection. It does not prove that the business is honest or that its application has no bugs.

What is it?

Caching means keeping a useful copy so you do not have to repeat expensive work every time.

Imagine you cook often. You keep salt near the stove instead of walking to a distant storeroom every time. The storeroom still holds your main supplies; the nearby salt saves time.

Example: product details

1. A customer asks for product 42.
2. The app checks the cache.
3. If the product is there, the app returns it quickly.
4. If it is missing, the app reads the database.
5. The app saves a copy in the cache for later requests.

A cache hit means the data was found. A cache miss means it was not found.

Where can caching happen?

Real-world use: Thousands of people open the same product page. A cache helps avoid asking the database the same question thousands of times.

What can go wrong?

The cached price might be old. Before accepting an order, check important facts such as price and stock against the correct authoritative data.

Remember: A cache makes repeated work cheaper, but you must decide how fresh the answer needs to be.

Let's use a restaurant-booking app.

You click Book a table. What happens behind the scenes?

These jobs may be combined in some systems. Every application does not need a separate product for every row.

The important detail: A menu image may come directly from the CDN. A new booking needs the booking service to safely change stored data. Different requests can follow different paths.

Where is this useful?

When you design an app, follow one request from start to finish. It helps you see which part is doing each job.

Remember: Each component should have a clear job. Do not add tools just to make the architecture look impressive.

API means Application Programming Interface.

An API defines how one piece of software can ask another piece to do something.

Think about a restaurant menu. It tells you what you can order. You do not need to know exactly how the kitchen prepares every dish. Similarly, an API tells your frontend what operations the backend offers and what information to send.

Example

GET /products/42

This asks the backend for product 42. The response might be:

{
  "id": 42,
  "name": "Keyboard",
  "price": 2500
}

The backend still does the actual work: checking rules, reading data, and returning the result.

What is an API gateway?

Imagine a receptionist at the entrance. You explain what you need, and the receptionist directs you to the right department.

A gateway receives API requests and sends them to the right service. It can also check login tokens, limit requests, and record traffic.

Real-world use: In a shopping app, /products goes to the catalog service and /orders goes to the order service.

Remember: An API is the agreed way to interact. A gateway is a component that handles incoming API traffic.

These are different ways to organize communication. You do not have to choose one for your entire application.

REST: ask for resources through endpoints

A resource can be a product, user, or order. You use an address and an HTTP method to say what you want.

Use it for: Ordinary web/mobile APIs such as products, orders, and profiles.

GraphQL: ask for the fields you want

Suppose a screen only needs a user's name and recent orders. You can describe those fields in one query:

query {
  user(id: "7") {
    name
    recentOrders {
      id
      status
    }
  }
}

The backend returns those requested fields. This can reduce extra data and client round trips.

Use it for: Screens that need different combinations of related data.

gRPC: call a method on another service

Imagine your order service asks the inventory service:

CheckStock(productId = 42)

It feels like calling a function, but the function runs in another service. gRPC uses a defined contract so both sides agree on the request and response.

Use it for: Communication between backend services.

WebSocket: keep a two-way conversation open

With normal repeated requests, a delivery app might keep asking, “Where is my driver now?” With a WebSocket connection, the server can send a location update when it has one. The client can also send messages back.

Use it for: Chat, auction bids, driver-location updates, and live scores.

Webhook: tell me when an event happens

Your payment provider should not need you to ask every second, “Has this payment finished?” You give it a backend URL. When the payment event happens, it sends a request to that URL.

Use it for: Payment updates, shipping updates, or notifications from an external service.

SOAP: exchange messages in a strict XML format

SOAP messages use a defined structure with an envelope and body. It is like filling out a formal form that both sides agree to understand.

Use it for: Integrating with systems that already require SOAP, including some enterprise and banking systems.

Remember: Pick communication based on the job. One app can use several approaches together.

SDK means Software Development Kit.

An API tells you how to interact with a system. An SDK gives you ready-made tools that make that interaction easier.

Imagine you want to assemble furniture. The instructions tell you what to do. A toolkit gives you the tools to do it more easily.

Example: adding a payment provider

Without its SDK, you might build the HTTP request, send it, read the response, and handle errors yourself.

With its SDK, you may call a helper like:

paymentClient.createPayment(details)

The SDK handles some of the request-building work for you.

Real-world use: Maps, payments, social login, and AI integrations.

Remember: API = the interface. SDK = tools that help you use the platform.

What is it?

Partitioning means splitting a large dataset into smaller parts.

Imagine a library puts every book in one giant pile. Finding a book is difficult. It divides books into sections: science, history, and literature. Now you can go to the relevant section.

Database example

Your orders table has years of orders. You divide it by year:

A query for 2025 may only need the 2025 partition.

Horizontal vs vertical partitioning

With vertical partitioning, keep a shared ID so the pieces can be linked again.

Real-world use: A large orders or event table becomes easier to search, archive, and maintain.

Remember: Partitioning organizes data into smaller parts. It does not automatically make every query faster.

What is sharding?

Sharding means putting different parts of a dataset on different database nodes.

Use the restaurant example:

• Local partitioning is like making separate counters inside the same restaurant.
• Sharding is like opening several branches and giving each branch part of the work.

How does the app know which shard to use?

It follows a rule or checks a mapping.

For example, with shard = user_id % 3, user 10 belongs to shard 1. When reading that user's data, the app applies the same rule and goes to shard 1.

Real-world use: A messaging application has too much data for one database node. It distributes conversations or users across nodes.

Remember: Sharding divides data across machines; you still need a reliable way to locate each piece.

Replication means making copies. Sharding means dividing data.

Imagine your notes are stored in one notebook.

Replication is making copies of the notebook. Sharding is putting chapters 1–3 in one notebook and chapters 4–6 in another.

How does replication work?

In a common setup, one database is the primary. Writes go there. Other databases, called replicas, copy its changes. Suitable read requests can go to replicas.

Real-world use: A shop's product catalog gets many reads. Read replicas can help serve them. If one database node fails, another copy may also help recovery when failover is properly configured.

Can we use both? Yes. Each shard can have its own replicas.

Remember: Copies help keep data available. Shards help divide a large workload. Neither solves every problem alone.

What are they?

A relational database organizes data into tables with relationships. SQL is the language commonly used to query such databases.

NoSQL is a broad name for several other data models, such as documents, key-value pairs, wide-column records, and graphs.

Do not start by asking, “Which one is always faster?” Ask, “What data do I have, and what do I need to do with it?”

Example: an online shop

When might relational storage fit well?

When relationships, constraints, transactions, and flexible queries matter. For example, connect customers to orders and order items.

When might a NoSQL model fit well?

When its particular model matches your needs. For example, key-value access for sessions or graph traversal for complex relationships.

Remember: Choose based on the job, not the SQL/NoSQL label alone.

What is it?

A document database stores a record as a document containing named fields, lists, and nested information.

Think of one product's information as a form. A TV form needs screen size. A shoe form needs shoe size. They do not have to contain exactly the same fields.

Example documents

{
  "id": "tv-1",
  "name": "Smart TV",
  "screenSize": 55,
  "resolution": "4K"
}

{
  "id": "shoe-1",
  "name": "Running Shoe",
  "size": 7,
  "color": "black"
}

How does it work?

You store and query these documents. Indexes help find documents by useful fields. MongoDB and CouchDB are examples of document databases.

Real-world use: Product catalogs, profiles, and content-management systems where records can have different details.

Where do images go?

Usually, keep the image file in object storage and save its key or reference in the document. A CDN can deliver it to users.

Remember: A document keeps related fields together while allowing different records to have different shapes.

What is it?

A key-value database saves a value under a key. You use the key to get the value back.

Think of a locker room. Your locker number is the key. The things inside are the value.

How does it work?

Save:  SET cart:user-7 = [keyboard, mouse]
Read:  GET cart:user-7

This is a simple illustration, not complete command syntax for every product.

Real-world use: Carts, sessions, cached data, and request counters. Redis is a common example; DynamoDB also supports key-value access patterns.

What is the limitation?

It is convenient when you know the key. A question like “find every customer who bought a laptop last month and calculate average spending” may need a more suitable query model or extra indexes.

Remember: Know the key, find the value.

What is it?

A wide-column database organizes records around keys and columns and is designed to handle large datasets across machines. Cassandra, HBase, and Bigtable are examples, though they differ in their details.

This is one of the harder topics, so start with the use case.

Example: temperature sensors

Suppose thousands of devices send temperature readings all day. You usually ask, “Show this device's readings for this day.”

You can group records by device and day:

The design helps the database go to the relevant group instead of treating every reading as part of one undivided pile.

Real-world use: Large event, sensor, and time-series workloads with known access patterns.

Important clarification: The script mixes wide-column databases with analytical columnar storage. Those are different ideas.

Remember: Start with the queries you need, then choose keys and groups that support them.

What is it?

A graph database focuses on things and the connections between them.

A thing is called a node. A connection is called an edge or relationship.

How does it work?

The database follows relationships to answer a question. For example: “Which of my friends work at Company A?”

Following connections is called a traversal.

Real-world uses

• Suggest mutual friends or professional connections.
• Find films related to films a user liked.
• Find suspicious groups of accounts sharing devices or payment details.
• Connect people, places, and facts in a knowledge graph.

Neo4j, Amazon Neptune, and TigerGraph are examples.

Remember: Graph databases are especially useful when relationships are the main part of the question.

What problem is CAP talking about?

Imagine you have two database servers that normally share updates. Suddenly, the network between them breaks. Both servers are running, but they cannot talk to each other.

Now one server changes a value. What should the other server do when someone asks for that value?

That is the kind of problem CAP helps explain.

A network partition is this communication failure. It is different from splitting a database table into partitions.

The difficult choice

During the network break, the second server cannot know the latest change.

• It can continue answering, but its answer may be old.
• Or it can wait/refuse an operation that it cannot safely complete with the required consistency.

It cannot guarantee both properties for every operation while the communication problem lasts.

Real-world examples

For a public like count, showing a slightly old value may be acceptable.

For selling the last seat, accepting two conflicting bookings is not acceptable. It can be better to reject an attempt than confirm a seat you cannot safely allocate.

Remember: If servers cannot communicate, you may have to choose between waiting for a safe answer and continuing with weaker consistency.

First, what is a transaction?

A transaction is a group of database operations treated as one unit of work.

Suppose you move 50 from account A to account B inside one database. You want both changes to happen correctly: subtract 50 from A and add 50 to B.

ACID describes useful transaction guarantees.

Simple number example: A has 100 and B has 200. Transfer 50. A becomes 50; B becomes 250. The total stays 300 when there are no fees.

What is BASE?

BASE describes an approach where some data can catch up later while the service remains useful.

Example: You like a post. Your friend's screen may take a moment to show the new total. A short delay can be acceptable for that count.

Remember: ACID protects a transaction's correctness. BASE allows suitable parts of a system to catch up over time.

What is a message queue?

A message queue holds work so another program can process it later.

Imagine a restaurant order slip. The waiter gives your order to the kitchen, and the kitchen prepares it when a cook is ready. The waiter does not need to stand still until the entire meal is finished.

Example: sending an order email

1. Your backend safely saves an order.
2. It creates a task: “Send confirmation for order 42.”
3. The queue holds that task.
4. A worker picks it up and sends the email.
5. If sending fails, the system can try again according to its rules.

Synchronous: “I ask and wait for your answer before continuing this operation.”

Asynchronous: “I arrange the work, and completion happens separately.”

Real-world use: Emails, notifications, image processing, and background order tasks. The user does not have to wait for every supporting job.

Important: “Your request is queued” does not always mean “your purchase is confirmed.” Only claim the result that has actually been safely recorded.

Remember: Queues let work happen separately in time. They still need correct failure handling.

What problem do these solve?

You have a value in a cache and a saved copy in a backing store, such as a database. If you change the cached value, when should the backing store change?

Suppose both places contain x = 100. Now you want x = 200.

Simple analogy

Write-through is like updating both your working note and official register before saying, “Done.”

Write-back is like updating your working note immediately and planning to update the official register later.

What is the trade-off?

Write-through includes the backing-store work, so the write may take longer.

Write-back can respond sooner, but you must protect updates waiting to be saved. If the only copy disappears before it is written back, you can lose the change.

Real-world use: Some noncritical counters can be collected and written later. Important acknowledged data needs a stronger durability plan.

Remember: Write-through waits for the backing write. Write-back delays it and must safely track unfinished work.

What is rate limiting?

Rate limiting controls how much work a client may request over time.

Imagine a ticket counter says, “One person can make only five booking attempts per minute.” This prevents one person from taking all the counter's attention.

Why use it?

To protect server capacity, reduce repeated login guesses, control API costs, and give users a fair share.

An HTTP API often returns 429 Too Many Requests when a limit is reached.

1. Fixed window counter

Divide time into fixed periods. Allow ten requests in each minute.

It is simple, but ten requests at the end of one minute and ten at the start of the next can create a burst of twenty close together.

2. Sliding window log

For every new request, look backward over the last 60 seconds and count requests in that period.

The window moves with time. It does not simply reset at the start of each clock minute.

3. Sliding window counter

Estimate recent usage using the current window's count and part of the previous window's count. It uses less memory than storing every request time, but the result is an estimate.

4. Token bucket

Imagine a bucket holding ten permission tokens. Each request uses one token. New tokens are added at a fixed rate, up to the bucket's capacity.

If the bucket is full, a short burst is allowed. When empty, requests must wait or be rejected according to the policy.

5. Leaky bucket

Imagine requests waiting in a bucket with a small outlet. They leave at a steady rate. If the bucket is full, extra arrivals are rejected.

This smooths bursts but can add waiting time.

Real-world uses: Login attempts, paid API quotas, booking attempts, and limiting calls to another company's API.

Remember: Choose whether you want to count recent usage, allow bursts, or smooth incoming work.

What is it?

Microservices means dividing an application into services that can be developed and deployed independently around clear business jobs.

Imagine a large restaurant. One team handles orders, one handles cooking, and one handles delivery. Each team has a clear responsibility, but they still need to communicate.

Example: grocery app

A dark store is a location used to fulfill online orders rather than an ordinary walk-in shop.

What is a monolith?

A monolith is one deployable application. It can still have well-organized modules and can run on several servers.

When should you use microservices?

When independent teams, deployment needs, or different scaling requirements justify the added complexity. A small project does not become better just because it has many services.

Containers and Kubernetes, simply

A container packages your application and its dependencies so it runs in a predictable environment.

Kubernetes helps manage containerized applications: where they run, how they restart, and how the number of running copies changes.

Remember: Split services for a clear reason. A well-organized monolith is often a strong starting point.

What is SOLID?

SOLID is a set of five principles for organizing object-oriented code so changes are easier to manage.

Imagine you replace a kitchen tap. You should not have to rebuild every wall in the house. Good code design tries to make changes similarly contained.

S — Single Responsibility

Give a class one clear, related job.

Bad example: one class registers users, formats emails, writes audit files, and generates reports.

Better: registration handles registration, an email component handles emails, and an audit component handles audit records.

O — Open/Closed

Make expected new behavior easy to add without repeatedly changing stable code.

Example: different payment providers implement a common payment interface. Adding another provider does not require editing payment conditions all over the app.

L — Liskov Substitution

If a class claims to be a kind of another class, it should fulfill the behavior callers expect.

Example: if Bird promises fly(), a penguin cannot safely fit that promise. Put flying behavior in a suitable separate capability instead.

I — Interface Segregation

Do not force a component to depend on methods it does not need.

Example: a print-only device should not be forced to implement scanning and faxing. Give those capabilities separate interfaces.

D — Dependency Inversion

Let important business code depend on an agreed interface rather than one provider's exact implementation.

Example: order code depends on PaymentGateway. An adapter connects that interface to your chosen provider.

What are coupling and cohesion?

Coupling is how much one part depends on another part's details. Less unnecessary coupling makes changes easier.

Cohesion is how closely the jobs inside one part belong together. A class that does one related job has stronger cohesion than a class containing random unrelated tasks.

interface PaymentGateway {
  pay(amount: number): Promise<void>;
}

class OrderService {
  constructor(private gateway: PaymentGateway) {}

  async checkout(amount: number) {
    await this.gateway.pay(amount);
  }
}

Remember: The goal is understandable, changeable code—not the maximum possible number of classes.

Why do we need several layers?

Think of a house. A gate helps, but you may also need a door lock and a safe for important things. One protection should not be your entire security plan.

An application also protects different things at different places.

Authentication vs authorization

You log in successfully: the system knows which account you are using.

You try to delete another person's order: the system must still check whether you are allowed to do that.

Being logged in does not mean you can do everything.

Password protection

Do not save a plain password. Store a suitable password hash with a salt. A hash is a one-way result used for verification. It is not a password encrypted for later decryption.

Real-world use: In a delivery app, a driver can manage an assigned delivery but should not be able to give themselves admin permissions.

Remember: Check both identity and permission. Protect the data and the infrastructure too.

What is a JWT?

A JWT is a format for carrying claims. A claim is a statement such as “this token is for user 7” or “this token expires at this time.”

Imagine an event pass. You first prove you are allowed into the event. Then you show the pass at different checkpoints instead of repeating the entire registration process.

A signed JWT works somewhat like that pass.

How does it work?

1. You log in.
2. The server checks your credentials.
3. It gives you a token.
4. Your app sends that token with later requests.
5. The receiving service checks that the token is valid before using its claims.

What is inside a typical signed JWT?

header.payload.signature

Real-world use: Several services can check a trusted token when handling API requests.

Very important: A usual signed JWT is not secret inside. Its payload can be decoded and read. Do not put passwords or secret keys in it.

Remember: A JWT carries claims. Correct validation makes those claims useful; the token's presence alone proves nothing.

What is a session?

A session lets the server remember a logged-in user.

Imagine leaving a bag at a cloakroom. You receive a random ticket number. The staff keep the information about which bag belongs to that number.

A server-side login session is similar:

1. You log in.
2. The server saves session information.
3. It gives your browser an unpredictable session ID, usually in a cookie.
4. The browser sends the ID with later requests.
5. The server looks up the matching session.

How is that different from a JWT?

Can sessions work with multiple servers? Yes. The servers can share a session store, such as Redis. The session does not have to exist only in one server's memory.

What is OAuth?

OAuth is a way to let another application access specific things without giving it your account password.

Think of giving a valet limited permission to park your car. You do not also give access to your house.

Example: Let a scheduling application read your calendar without allowing it to change everything in your account.

What is OIDC?

OpenID Connect adds identity/login information on top of OAuth 2.0. It helps an application learn who signed in through an identity provider.

What is SSO?

Single Sign-On means signing in once and then accessing participating applications without separately logging in to each one.

Example: Your company login gives you access to its internal tools.

Remember: Sessions remember login state, JWTs carry claims, OAuth delegates access, OIDC supports identity login, and SSO reuses sign-in across apps.

What are we building?

An app where people create profiles, follow others, upload photos/videos, see a feed, like/comment, send messages, and receive notifications.

Start with the main parts

Stories and reels have their own product rules. Live features may need separate media delivery and real-time control systems.

What happens when you upload a video?

1. The app checks that you are allowed to upload.
2. The video file is uploaded to storage.
3. A background task checks and processes it.
4. Workers create suitable video versions and thumbnails.
5. The app marks the post ready.
6. Your followers can discover it in their feeds.
7. A CDN helps deliver the video to viewers.

Why create several video versions?

One person has fast internet; another has slow internet. Different video sizes/qualities help the player choose something suitable. Converting media into these versions is called transcoding.

What happens when someone opens the feed?

The feed service finds possible posts, removes unsuitable ones, chooses an order, and returns post information. The client then loads media from delivery servers.

Recommendation words, simply

For example, even if one creator has many highly ranked posts, the app may avoid showing ten of their posts in a row.

Remember: Media delivery, post metadata, feeds, and notifications are different jobs. Give each job a suitable design.

What are we building?

An app where people search trains, check seats, book, pay, cancel, and receive tickets.

The hardest situation is a booking rush: many people want a small number of seats at the same time.

Two separate problems

• Scaling: How do we handle all the requests?
• Concurrency control: How do we stop two requests from confirming the same seat?

Adding servers helps with the first problem. It does not automatically solve the second.

Main parts

Simple safe booking flow

1. You choose a train and request a seat.
2. The backend safely creates a temporary hold if a seat is available.
3. The hold has a time limit.
4. You complete payment.
5. The backend verifies the payment result.
6. If the valid hold still belongs to you, it confirms the booking.
7. A background worker sends the ticket.
8. A failed or expired attempt releases the hold according to the rules.

What is a hold?

It is a saved reservation saying, “This seat is temporarily reserved for this booking until a certain time.” It gives the user time to pay.

Why not just check and then book?

Suppose both Sandeep and Priya read “one seat left.” Both then try to buy it. Reading availability alone does not decide the winner. The database must safely combine the decision and update so both cannot succeed.

UPDATE seat_inventory
SET status = 'HELD', hold_id = :hold_id
WHERE journey_id = :journey_id
  AND seat_id = :seat_id
  AND status = 'AVAILABLE';

Remember: Handle traffic with capacity controls. Protect seats with correct data operations. Treat payment and notification failures separately.

What is UPI?

UPI means Unified Payments Interface. It is an Indian payment system operated by NPCI. It lets people initiate payments through participating apps and institutions.

For learning, focus on the roles and flow. This is not a complete technical integration guide.

Who does what?

A VPA, or Virtual Payment Address, is commonly called a UPI ID. A QR code can contain the address and other payment information.

A simplified payment flow

1. You open an app and choose the recipient and amount.
2. You authorize the payment through the required flow.
3. The request reaches the UPI system through the app's PSP arrangement.
4. NPCI routes messages to the relevant participants.
5. The payer's bank checks and processes the debit according to its rules.
6. The recipient's bank processes the credit.
7. Status information comes back to the app.

The PSP bank and the bank holding your account can be different. Money does not have to enter a separate app wallet just because you used that app to initiate the payment.

What can we learn for system design?

Payment processing needs safe records, duplicate protection, controlled access, monitoring, and recovery when a participant or network has a problem.

Remember: The app starts the user's request. The payment network and banks coordinate the actual operation, and uncertain outcomes require careful recovery.

1. Ask what the system must do. For example: search trains, book seats, cancel tickets.
2. Ask what must never go wrong. For example: never confirm one seat for conflicting bookings.
3. Estimate the workload. How many users, reads, writes, and files? What is the busiest period?
4. Draw the simplest useful design. Client, API/backend, and database are a good starting point.
5. Follow one read and one write. Explain each component's job.
6. Find the likely bottleneck. Add caching, indexes, replicas, or more servers for a reason.
7. Walk through a failure. What happens after a timeout, duplicate request, or server crash?
8. Explain security and monitoring. Who can access what, and how will you notice problems?
9. Explain the trade-off. What does your choice improve, and what becomes harder?

Functional requirements describe what the system does. Nonfunctional requirements describe qualities such as speed, availability, security, and scale.

For a rough average: requests per second = daily requests ÷ 86,400. The busiest moment can be much higher than the average.

Do not just list Redis, Kafka, Kubernetes, and five databases. Explain the actual problem each one solves. If you cannot explain why a component is needed, the design may not need it yet.

The uploaded script provides the topic outline. These references support the technical clarifications. You do not need to read them before understanding the beginner explanations.

• IANA: root DNS servers
• RFC Editor: TLS 1.3
• PostgreSQL: table partitioning
• MongoDB: document limits
• Apache Cassandra: architecture
• Apache Cassandra: data definition
• Martin Kleppmann: A Critique of the CAP Theorem
• Redis: rate-limiting algorithms
• RFC Editor: JSON Web Token
• Auth0: OAuth 2.0
• Auth0: OpenID Connect
• NPCI: about UPI
• Google Pay: UPI participant responsibilities