Scenario based Software Engineer interview questions

Measure first, then optimise the part that matters.

This is I/O-bound. Run the calls at the same time with asyncio (or a thread pool if the client library is blocking). Also limit how many run at once.

Stream it instead of loading it. File objects are lazy iterators over lines, so memory stays flat.

Confirm it is a leak (memory rising steadily and never plateauing), then find what holds references.

• Take snapshots with tracemalloc and compare them to see which lines allocate the growing objects:

CPU-bound work is limited by the GIL, so use processes or vectorisation, not threads.

• First check if the work can be vectorised with NumPy or pandas. This moves loops into C and is often 10 to 100 times faster.
• Otherwise split the data into chunks and use ProcessPoolExecutor:

Give each project its own virtual environment and pin its dependencies.

Wrap the call in a loop. Catch only errors worth retrying, wait longer each time, add jitter (a small random delay), and give up after a limit.

A process has its own memory space, a thread shares memory with others in the same process. Threads are lighter, but shared data needs synchronisation.

Safe ways to share:

• queue.Queue: thread-safe producer-consumer channel, the preferred approach.
• threading.Lock around read-modify-write sequences.

The problem: requests can return out of order. A slow response for an old query arrives last and wins.

Use try/catch around await, or .catch() on promise chains. A thrown error in an async function becomes a rejected promise.

Approach: reproduce, measure, compare, fix.

The work runs on the main thread, so it blocks rendering and input. Confirm with the DevTools Performance tab (a long task).

Fire all 1,000 at once and you will hit rate limits or exhaust the browser. Use a pool: start up to 5 workers that each pull the next id until none are left.

Retry only temporary failures (network errors, 5xx, 429). Wait longer each time. Add jitter (a small random delay) so many clients do not retry together. Limit the number of attempts. Do not retry 4xx client errors. Retry non-idempotent requests (like POST) only if the server supports idempotency keys.

Use a Map or object for O(n) work instead of nested loops.

Fix it on both sides, because client checks alone can be bypassed.

Client:

• Disable the button and show a spinner as soon as the submit starts. Enable it again in finally.
• Guard with a flag so a second handler call returns early.

Rank within each department using a window function, then filter.

Group by the columns that define a duplicate and keep groups with more than one row.

Measure before changing anything.

Make the check and the update atomic using row locking or a constrained update.

Option 1, pessimistic lock:

Start from the execution plan, then work through the options in order of effort.

Use an anti join: LEFT JOIN and keep rows with no match, or NOT EXISTS.

Truncate the date to the month, filter the range, group and sort.

Simple pagination uses LIMIT and OFFSET. But the database must read and throw away all skipped rows, so page 10,000 is slow.

Common reasons the planner ignores an index:

Avoid anything that locks or rewrites the whole table during peak traffic.

One giant DELETE holds locks for a long time, bloats the transaction log and can stall replication. Delete in small batches instead.

Use a junction (bridge) table. It holds the foreign keys of both sides, plus any attributes of the relationship itself.

Compare each salary to a per-department average, using a join or a window function.

Use SUM() OVER with an ordered window.

For simple conditional logic, CASE inside a query is enough and keeps everything portable. To pivot rows into columns, combine CASE with an aggregate.

Use a subquery that takes the maximum of everything below the overall maximum.

Capture evidence, find what is retaining memory, fix it, and add a guard.

Measure before changing anything, and narrow down from the outside in.

count++ is not atomic (read, add, write), so threads overwrite each other's updates. This is a race condition.

The most likely cause is a key whose hashCode or equals changed after it was added, or a broken hashCode/equals pair.

It happens when a collection is structurally modified during iteration by anything other than the iterator itself. The fail-fast iterator compares a modCount and throws.

Enable caching with @EnableCaching and annotate methods. Back it with Caffeine for in-process or Redis for shared caches.

Never return unbounded lists. Accept page, size and sort parameters, validate them, and return a page with metadata.

Read the failure analysis: it names the missing bean and the injection point.

Find the problem first with the React Profiler and the browser Performance tab. Then reduce what is rendered and re-rendered.

1. Virtualise (windowing): render only visible rows using react-window, @tanstack/react-virtual or similar. This is usually the biggest win.
2. Paginate or filter on the server if users never need all rows at once.
3. Stop needless re-renders: stable keys, React.memo on the row, useCallback for handlers, and keep per-row state inside the row.
4. Move fast-changing state (like a search input) so it does not re-render the list; use useDeferredValue for filtering.
5. Avoid expensive work in render: precompute or memoise sorting and formatting.
6. Keep row DOM small and avoid layout thrash.

Confirm with before-and-after measurements.

What they are checking: Whether you measure and reach for virtualisation

Causes are usually one of these:

• Calling a setter during render: <button onClick={setOpen(true)}> runs immediately; it must be onClick={() => setOpen(true)}.
• An effect that sets state it also depends on, with no guard:

useEffect(() => { setItems([...items, 1]); }, [items]); // loops forever

• A dependency that is a new object, array or function on every render (useEffect(fn, [{ a: 1 }])). The effect then re-runs each time and sets state.

Fix:

• Move calculations into render (derived state) instead of effect plus setState.
• Use functional updates (setItems(prev => ...)) so you do not need the value as a dependency.
• Memoise object dependencies with useMemo or depend on primitives.
• Check the call stack and use the lint rule react-hooks/exhaustive-deps. Add a console log to see which dependency changes.

What they are checking: Whether you can find the loop cause quickly

This is a stale closure (the callback holds an old value). The effect ran once with []. So the callback captured count from the first render and keeps using it.

Responses can arrive out of order, so an older request overwrites the newer one. Cancel or ignore old requests in the effect cleanup.

Split state by type and use the simplest tool for each.

Use a framework with server rendering, most pages as static or incrementally regenerated: Next.js (App Router) or similar.

Move the data logic into a custom hook that returns { data, error, loading }. Use an AbortController so a slow earlier request cannot overwrite a newer one.

Each keystroke updates state at the top, which re-renders everything beneath.

React preserves state only while the component keeps the same type at the same position (and key). Resets usually come from:

Treat every request as having four states: loading, error, empty and success, and design each one.

Types do not exist at runtime, so a fetch().json() result typed as User is just a guess. Check the data where it enters your app, using a runtime schema library (Zod, Valibot, ArkType). Get the static type from the schema, so the two never get out of sync.

import { z } from "zod";

const UserSchema = z.object({
  id: z.number(),
  name: z.string().min(1),
  email: z.string().email().optional(),
});
type User = z.infer<typeof UserSchema>;

async function getUser(id: number): Promise<User> {
  const res = await fetch(`/api/users/${id}`);
  if (!res.ok) throw new Error(`HTTP ${res.status}`);
  const json: unknown = await res.json();
  return UserSchema.parse(json);       // throws a clear error if the shape is wrong
}

Practical points:

• Treat all external input (network, localStorage, query string, env vars) as unknown until parsed.
• Use safeParse where you want to handle errors without exceptions.
• Share the schema between client and server so both validate the same contract.
• Hand-written type guards work for tiny shapes but get long fast.

What they are checking: Whether you understand the limit of static types and validate untrusted data at the edge

I would never trust the type for data from outside the program. The flow:

1. Define the expected shape once as a runtime schema (Zod or similar) and infer the TypeScript type from it.
2. Keep the raw result as unknown and parse it in one wrapper function so nobody reads unvalidated data.
3. Handle failure on purpose (bad status, bad shape). Return a result type or throw a typed error.

import { z } from "zod";

const Todo = z.object({ id: z.number(), title: z.string(), done: z.boolean() });
type Todo = z.infer<typeof Todo>;

async function fetchJson<T>(url: string, schema: z.ZodType<T>): Promise<T> {
  const res = await fetch(url);
  if (!res.ok) throw new Error(`Request failed: ${res.status}`);
  const body: unknown = await res.json();
  return schema.parse(body);
}

const todos = await fetchJson("/api/todos", z.array(Todo));

If the backend is also TypeScript, share the schema package or generate types from an OpenAPI/GraphQL spec. Then a contract change breaks the build instead of production. A bare as Todo[] cast is acceptable only for trusted internal data and should be a conscious exception.

What they are checking: Whether you validate at the boundary and keep a single source of truth for the contract

When a value has a union type, you can only access properties that exist on every member. TypeScript does not know yet which member you have. So using a property that exists on only one of them is an error.

Migrate gradually so the app keeps shipping.

Describe all endpoints in one map type, then make a generic function that looks up the types by path. The compiler then knows the body and the result for each call.

Use a discriminated union instead of separate boolean flags, so impossible combinations (loading and error at once) cannot exist.

Use a generic with a conditional return type, or overloads, so the output depends on the input.

First measure, then reduce the work.

Contain the unsafety at the boundary so any never leaks into the rest of the code.

The bundler does the emitting, so TypeScript is used only for checking.

Enable it gradually and stop the debt from growing.

Find where the time goes before changing anything.

1. Check whether the route is rendered dynamically on every request when it could be static or cached. Look for cookies(), headers(), searchParams or cache: "no-store" forcing dynamic rendering.
2. Measure the server: log timing around each fetch and database call, or use OpenTelemetry. Look for slow queries, missing indexes and N+1 patterns.
3. Remove request waterfalls: start independent fetches together with Promise.all.
4. Cache what can be cached: revalidate, tags, or "use cache" in Next 16; a CDN in front for public pages.
5. Stream: wrap slow, non-critical sections in Suspense so the shell is sent immediately.
6. Reduce work in middleware and avoid heavy computation on the request path.
7. Check geography: server and database should be in the same region, and users far away should hit a CDN.
8. Check cold starts and memory limits on serverless platforms.

const [user, posts] = await Promise.all([getUser(), getPosts()]); // parallel, not sequential

Verify with real field data (Core Web Vitals, server timing headers), not only local runs.

What they are checking: Whether you follow a measurement-driven approach and know Next-specific causes

This is a caching question. Walk the layers from server to browser.

1. Static or ISR page: the page was generated earlier and revalidate has not passed. Fix with on-demand revalidation (revalidatePath or revalidateTag) after writes, or lower the interval.
2. Data cache: a fetch with force-cache or a long revalidate. Use tags and invalidate them, or cache: "no-store" for truly live data.
3. Full route cache and generateStaticParams: new slugs need dynamicParams true or a rebuild.
4. Router cache in the browser: soft navigation may show a previous payload. Call router.refresh() after a mutation, or use Server Actions which refresh automatically.
5. CDN or reverse proxy cache (Cloudflare, nginx): check Cache-Control and purge. Verify with curl -I and the x-nextjs-cache header (HIT, MISS, STALE).
6. Multiple instances with separate in-memory caches: a revalidation reached only one server. Use a shared cache handler.
7. Read-replica lag or a wrong environment variable pointing at old data.

curl -sI https://example.com/blog/post | grep -i -E "cache|age|x-nextjs"

Fix by deciding the freshness requirement per page, then invalidating explicitly on write.

What they are checking: Whether you can systematically debug stale data across caches

Hydration attaches React to server HTML. If the first client render produces different markup than the server did, React reports a mismatch.

Common causes:

• Values that differ between server and client: Date.now(), Math.random(), new Date().toLocaleString() (time zone and locale differ).
• Reading window, localStorage or navigator during render.
• Invalid HTML nesting, such as a <div> inside a <p>, which the browser repairs.
• Browser extensions injecting attributes, or inconsistent conditional rendering based on the user agent.

Fixes:

"use client";
import { useEffect, useState } from "react";

export function Clock() {
  const [now, setNow] = useState<string | null>(null);   // same on server and first client render
  useEffect(() => setNow(new Date().toLocaleTimeString()), []);
  return <span>{now ?? ""}</span>;
}

• Compute browser-only values in useEffect, so the first render matches.
• Use useId for ids, and pass stable data (like a server-generated timestamp) as props.
• Fix invalid nesting.
• Use suppressHydrationWarning only for unavoidable one-off text such as a timestamp.
• next/dynamic with ssr: false for components that cannot render on the server.

What they are checking: Whether you can reason about server versus client render output

Use layers, and put the real check next to the data.

Work from what Google sees to how the page is built.

First find the LCP element in Lighthouse or Chrome DevTools (usually a hero image or a big heading). Then remove what delays it.

Migrate incrementally, because both routers work in the same project. If a path exists in both, app/ wins, so move one route at a time.

Build in CI, not on the small server, and ship only the output.

Never render them all. Paginate or stream, and let the database do the work.

Put the variable part in a dynamic top-level segment and resolve it early.

Reduce the cost per request first, then restrict abusers, without blocking real users or search engines.

Stop building on the production machine, and shrink the build.

First measure with the Angular DevTools profiler and the Chrome Performance tab. Then reduce what is drawn and what is checked.

This pattern usually means leaked subscriptions, listeners or detached DOM. Confirm it with a heap comparison, then fix the code that owns them.

Use a form control stream with debounce, removal of repeated values and switchMap. Handle loading and errors without breaking the stream.

Measure first (Lighthouse, ng build --stats-json with a bundle analyser), then cut what ships and defer the rest.

Catch 401 responses and refresh the token once. Hold the other failed requests until the refresh finishes. Then retry them with the new token.

It happens in development mode. A binding's value changes after Angular has already checked it in the same cycle. Usually a child or a lifecycle hook changes parent state during the check.

Use a reactive form and drive the dependent controls from the parent control's valueChanges. Reset the children when the parent changes.

Check that the template is told something changed. OnPush only refreshes when an input reference changes, on template events, on async pipe or signal updates, or on markForCheck.

Migrate step by step, because NgModules and standalone components work together. Use the schematic to do most of the routine work.

Put the shared state in a service that both components inject. Expose it as a read-only signal or observable. Neither component should know about the other.

Confirm it is a leak: memory climbs and does not drop after garbage collection. Then check process.memoryUsage() or metrics for heapUsed and RSS over time.

Find it:

1. Run with node --inspect, connect Chrome DevTools, and take heap snapshots under load a few minutes apart. Use the Comparison view to see which object types grow. Then read what keeps them alive (their retainers).
2. Or use --heapsnapshot-signal=SIGUSR2 in production-like environments, or tools such as clinic.js.

Typical causes:

• Unbounded in-memory caches or maps keyed by user id.
• Event listeners added per request and never removed (the "MaxListeners" warning is a hint).
• Closures holding large request objects, global arrays that accumulate, timers never cleared.
• Un-ended streams or unclosed connections.

Fix: bound caches (LRU with a max size and TTL) or move them to Redis, remove listeners, clear timers, close resources. Verify memory plateaus under load. Setting --max-old-space-size only delays the crash.

What they are checking: Whether you debug with heap snapshots, not guesses

Node runs your code on one thread, so a hot function blocks all requests.

Diagnose:

• Capture a CPU profile: node --prof and node --prof-process, clinic flame, or Chrome DevTools via --inspect. Read the flame graph for the widest functions.
• Check event loop lag (perf_hooks.monitorEventLoopDelay) and which endpoint correlates with the spike.

Common culprits and fixes:

• Large JSON.parse/stringify, sorting or looping over big arrays: paginate, stream, or process in chunks with setImmediate.
• Synchronous crypto or hashing: use async versions or worker threads.
• Catastrophic regex backtracking: fix the pattern or limit input size.
• Complex per-request computation: cache results, precompute, or move to a worker pool or separate service.

Then run one process per core (cluster or containers). That way one busy process does not take down all capacity. Add load tests to confirm the fix.

What they are checking: Whether you profile and know the single-thread consequence

Work from measurement to cause.

Never buffer the whole file in memory. Stream it end to end and batch the writes.

Counters must be shared across instances, so use a central store (Redis), not in-memory counters per process.

Combine graceful shutdown with a rolling or blue-green deploy.

Act in layers, fastest wins first.

Likely suspects:

Stateless JWTs are valid until they expire, so revocation needs extra design.

Measure first, find the bottleneck layer, then fix and verify.

This is the captive dependency problem. The singleton holds the first scoped instance forever, so a DbContext is shared across requests and threads. It is not thread safe, it caches tracked entities (stale data) and grows without bound.

Many closures read the loop variable after the loop has advanced, so you may see repeated or unexpected values.

Find what is kept in memory, using dumps and counters. Then fix the root cause.

Treat it as an evidence hunt: narrow what the failing requests have in common.

Make the operation idempotent on the server, and do not rely only on disabling the button.

Use a hosted service for in-process work, and a durable job system when jobs must survive restarts.

Migrate incrementally and keep the system running, rather than a risky big-bang rewrite.

Move each branch's behaviour into a class that implements a shared interface, and let dynamic dispatch pick the branch.

Before:

Clarify requirements first: vehicle types, number of levels, pricing, entry and exit, payment, capacity display.

Apply Open/Closed with a Strategy interface and a registry.

Use Strategy for channels. Use a factory or registry to look them up. Use Observer if one event goes to many subscribers.

This breaks the Liskov Substitution rule: the child cannot honestly stand in for the parent.

The problem is hidden global state plus hard-wired access.

This is the fragile base class problem. Approach:

This is the telescoping constructor smell. Options:

Plan:

1. Add tests around the public behaviour (characterisation tests), even rough ones.
2. Group methods and fields by the data they touch. Clusters that use separate fields are separate responsibilities.
3. Extract classes one at a time (Extract Class refactoring). Move a cluster and its fields to a new...

A trie keyed by characters supports prefix lookup in O(L). Store a small list of top suggestions at each node (worked out in advance by frequency). Then a query returns results without walking the whole subtree.

Exact counting needs memory proportional to distinct items. Options:

Model users as vertices and friendships as edges (unweighted, undirected). Use BFS from the source: the first time you reach the target is the shortest path, in O(V + E).

A sorted array gives O(log n) search but O(n) insert/delete because of shifting. A plain linked list gives O(1) insert but O(n) search.

Inserting keys in sorted order into a plain BST creates a lopsided tree. Every node has only a right child, so it behaves like a linked list. Height becomes n and operations degrade from O(log n) to O(n).

Options by constraint:

1. External sort: sort chunks that fit in memory, write them out, k-way merge, and compare neighbours. O(n log n) with sequential disk I/O, exact.
2. Hash partitioning: split IDs into buckets on disk by hash(id) % B, so duplicates fall in the same bucket. Then check each bucket in...

Use two stacks of commands (Command pattern).

A priority queue implemented with a binary heap: insert and pop-highest are both O(log n), peek is O(1). A sorted list would make inserts O(n).

Combine a hash map (O(1) lookup) with a structure that tracks recency. In Python, OrderedDict is a hash map plus doubly linked list, with move_to_end and popitem.

Keep a second stack (or store pairs) that tracks the minimum at each depth. Every push records the smaller of the new value and the current minimum.

Use an input stack for pushes and an output stack for pops. When the output stack is empty, move everything over, which reverses the order to FIFO.

Use a sliding window log per user: keep the timestamps of recent requests in a deque. Drop the ones older than the window. Allow the request if fewer than N remain.

Treat AI output like code from a new teammate: useful, but unreviewed. I never merge what I cannot explain line by line.

Keep two heaps: a max-heap for the lower half and a min-heap for the upper half, sizes balanced within one. The median is the top of the larger heap, or the average of both tops.

Store timestamps in a deque (hits arrive in time order). On each query, drop entries older than 300 seconds and return the length. For very high traffic, count into per-second buckets in a fixed array of 300 slots.

Store (value, expires_at) in a dict. Check expiry lazily on reads. A background sweep (or heap ordered by expiry) removes dead entries so memory does not grow without bound.

Give each URL an auto-increment ID (from a database sequence or a distributed ID generator). Then encode the ID in base62 (0-9, a-z, A-Z). Decoding reverses it. This avoids collisions and gives short codes: 7 characters cover 62^7, about 3.5 trillion IDs.

Work in the smallest currency unit (integer cents or paisa), so there is no floating point error. Work out each share with integer division. Then give out the leftover units one by one, so the shares add up exactly to the total. This is the largest remainder method.

Resources: posts and comments (comments belong to a post).

Use idempotency keys on the non-idempotent POST calls.

Use many layers of defence:

First find the slow part with tracing, logs and database EXPLAIN. Then use the cheapest fix that works.

Postman does not enforce CORS. The browser does. So the problem is in the server response headers.

Do not keep the HTTP connection open. Use the asynchronous request-reply pattern.

The N+1 problem happens when you fetch a list and then run one extra query for each item to load related data. For example, 100 orders with their customers become 101 queries.

Keep old clients working while new ones move over.

Do not send 10,000 separate requests. Do not send one request that times out.

Measure first. Then remove the repeated queries.

1. Count queries with django-debug-toolbar or django-silk locally, or enable the django.db.backends logger. Tests can pin the number with self.assertNumQueries(3).
2. If the query count grows with the number of rows, it is N+1. Find the field that the serializer or template reads, which causes one query per object.
3. Fix in get_queryset: select_related for FKs, prefetch_related (with Prefetch objects for filtered relations) for reverse and M2M, and annotations for counts and sums.
4. Send less data: only()/defer(), paginate (PageNumberPagination or cursor pagination), avoid big nested objects.
5. Look at slow SQL with EXPLAIN ANALYZE and add indexes (db_index=True, Meta.indexes) on filtered and ordered columns.
6. If it is still slow, cache the result in Redis and measure again.

Goal: a small, fixed number of queries, no matter how many rows. Add a test to keep it that way.

What they are checking: Methodical diagnosis with ORM-level tooling

A slowdown that only appears with many users usually means requests are fighting for a limited resource.

Scale in steps. Start with the cheapest wins.

This is a race condition: the code reads first and writes later. Make the check and the update happen as one step in the database.

Option 1: lock the row.

Start with facts, not guesses.

Decide by needs, team and tools, not by hype.

Pick Django + DRF when:

• You need an admin panel, auth, ORM and migrations ready to use.
• The product is one big app built around a database, or has pages made on the server.
• The team knows Django, and you want proven conventions and many ready packages.

Keep only the essential work in the request. Move the slow parts out of it.

Avoid long locks. Make sure old code and new code both work during the rollout (add first, remove later).

Use many layers of defence.

Require an Idempotency-Key header made by the client. Store the key with a fingerprint of the request and the result. Then a repeat gets the saved response and does not run again.

Compare both sources by a stable key, classify the differences, and make the job re-runnable and auditable.

Measure first, then fix the biggest cost, which is usually the database.

This is a lost-update race. Prevent it by letting the database handle changes one at a time. Use an atomic update, a row lock, or optimistic versioning.

Find why each one needs the other. Then break the cycle by moving shared logic or reversing one direction, instead of leaving forwardRef everywhere.

Define one common interface and implement it for each gateway (adapter). Then pick the right one at run time (strategy) through DI.

Apply a global throttler, with a stricter limit on login routes. Count by IP and by account. Slow attackers down more after repeated failures.

Use a queue (BullMQ with Redis through @nestjs/bullmq) so work is persisted, retried and processed outside the request.

Verify authenticity, acknowledge fast, and process each event exactly once by its id.

Add liveness and readiness endpoints with @nestjs/terminus. Enable shutdown hooks, so work in progress finishes before the process exits.

Requirements: make a short link for a long URL, redirect fast, many more reads than writes (about 100 to 1), optional expiry, and click analytics.

Capacity example: 100 million new URLs per month, about 40 writes/s and 4,000 reads/s; 7 characters of base62 give 62^7, about 3.5 trillion codes.

API:

• POST /urls with {long_url} returns {short_url}.
• GET /{code} returns 301 or 302 to the long URL. Use 302 if you want every click tracked. Use 301 when browsers may cache it.

Key generation:

• Counter or ID generator encoded in base62: unique, no collisions, but predictable.
• Random 7 characters plus a uniqueness check (retry on collision).
• Pre-generated key service handing out unused keys in batches to app servers.

Storage: a key-value table code -> long_url, created_at, expiry, user_id. NoSQL (DynamoDB, Cassandra) or sharded SQL by code works.

Scaling reads: cache popular codes in Redis (LRU), put a CDN or edge in front, and run stateless app servers behind a load balancer.

Extras: rate limits, checks for abuse and malware, click analytics done later through a queue, custom aliases, and removing expired links.

What they are checking: Structured approach: requirements, API, storage, scale

Requirements: 1:1 and group chat, real-time delivery, message history, online status, read receipts, media sharing, and millions of users at the same time.

Core design:

• Connection: clients keep a WebSocket connection to a chat gateway. Gateways are stateless apart from the connection, kept behind a load balancer.
• Routing: a session service (Redis) maps user_id -> gateway. To send, the sender's gateway looks up the recipient's gateway and forwards the message.
• Offline users: store the message and send a push notification (APNs/FCM); deliver on reconnect.
• Persistence: save messages in a store split by conversation (Cassandra or DynamoDB). Key it by (conversation_id, message_id) with ids ordered by time, for ordering and paging.
• Ordering and delivery: per-conversation sequence numbers; at-least-once delivery with client acks and deduplication by message id.
• Groups: fan-out on write for small groups, via a queue (Kafka) for large ones.
• Media: upload to object storage (S3) with pre-signed URLs, send only the link in the message, and serve it through a CDN.
• Presence: heartbeats stored in Redis with TTL.
• Security: TLS, optionally end-to-end encryption.

Scale by sharding on conversation or user id and adding gateway instances.

What they are checking: Real-time architecture and delivery guarantees

Goal: limit each client to N requests per time window, with low cost and counters shared across servers.

Where: at the API gateway or middleware, before expensive work.

Requirements: multiple channels, millions of notifications, user preferences, reliable delivery, no duplicates, rate limits per provider.

Work from measurement to action.

Avoid two-phase commit across services (slow, fragile). Use the Saga pattern: a sequence of local transactions where each step has a compensating action.

Protect the critical path and shed the rest.

The key decision is fan-out on write versus fan-out on read.

Split by capability, keep the checkout path correct and the browsing path fast.

Low-level design questions test modelling, not scale. Follow a repeatable path.

Do not run LIKE '%term%' over a large table. Use a search index.

Requirements: upload, download, sync across devices, sharing with permissions, large files, versioning.

Goals: sub-millisecond reads, high availability, horizontal scale, bounded memory.

There are three common models, and the choice depends on isolation needs, number of tenants and cost.

Put authentication in one identity service (or a managed provider such as Keycloak, Auth0 or Cognito). Every other service trusts the tokens it issues. Services do not keep their own passwords.