6. System design

I treat this as the one independent SDE I live-round Rate Limiter, from an OA-plus-three loop, not UTA two-DSA, and I will not invent it as a Job 10454435 prompt. I start by pinning the key: per user, IP, API key, or route; N requests in W seconds; whether bursts are allowed; and whether reject means HTTP 429 with Retry-After, a queue, or a silent drop. On one process I implement allowRequest(key) with a HashMap of buckets and a lock, and I write a full token bucket: capacity tokens, refill over time, refuse when empty. I name the other four algorithms without coding them: fixed window is O(1) but can admit about twice the budget at a window boundary; sliding log is exact and O(n); sliding counter is O(1) and approximate, the Cloudflare or Kong style; leaky bucket smooths instead of bursting. Across ECS tasks the JVM map is wrong because a load balancer fans out, so state lives in Redis and the refill-and-decrement runs inside one atomic Lua script using Redis TIME, not each JVM wall clock. The limiter sits in gateway or middleware, composed as AND of per-user and global limits, not inside each use-case. If Redis dies I fail closed on checkout so the origin lives and the user sees false 429s; I fail open on a marketing pixel. Ylogx Redis is the bot cache that cut database latency 35 percent, not a shipped limiter, and I will not claim I built this at internships.

Example: key user:42:/checkout, capacity 10, refill 10 per second. Single box: token bucket in a synchronized HashMap; if tokens < 1 return 429 and Retry-After: 1. Three ECS tasks behind ALB: the same math in Redis Lua so two concurrent checkouts cannot each see 10 tokens. Payments: Redis timeout → deny. A status pixel: Redis timeout → allow and accept origin load.

If they probe: “Why not fixed window?” ~2× burst at the boundary. “Sliding log?” exact, memory O(n) timestamps. “Clock skew?” Lua TIME. “Hot key?” shard the key or local cache with reconcile — mention, do not novel-design. Count stays 1; not UTA; not Job 10454435.

Arijit’s AUTA Tech 2 had an unnamed system design after unnamed LPs; the prompt stays unnamed, and I will not fill it with lockers, Redis, or CampusToCareer “APIs, databases, caching layers.” This card is the clarify list I actually use: what is the user-facing verb; is the load single-box or do they have a QPS; which entities and ids; may a read be stale; single machine versus multi-AZ; what must not double-charge or double-ship. In about forty minutes I restate scope, draw four to six boxes they named, go deep on one hottest read or write plus one invariant, add a 10× bottleneck only if they asked for scale, then one failure and one metric. I do not open with Redis because a blog said AUTA system design equals caching. I do not copy Rate Limiter or SNS unless they said those words. If I stall, I list entities, the one happy-path method, and ask which axis they want: scale, consistency, or failure. If they later nod at a BI or chatbot domain, Ylogx REST plus Postgres plus Redis plus CloudFront, ALB, and ECS is my stack, and sub-210 ms or 99.9 percent uptime only if they ask what shipped. Placeholders stay FooService until they name the product.

Example: they say “users create reports.” I propose createReport, getReport, in-memory ConcurrentHashMap<ReportId, Report>, client → app → store, and I wait for a nod before adding a cache. I do not draw ALB, CloudFront, and RLS until they ask how I shipped a similar path, and I never stamp that diagram as Arijit’s question or as Job 10454435.

If they probe: “Start with caching.” I refuse until they name a stale-read allowance. “Is this Rate Limiter?” only if they said those words; count stays 1 and not UTA. “Multi-region?” I will not claim a named active-active that is not on the resume.

Kafka keeps order inside a partition, not across the whole topic, so two messages with different keys can finish in any order even if they were produced in sequence. The same key hashes to the same partition, so that key’s consumers see FIFO. Adding partitions increases consumer parallelism; it does not create a total order. Synchronous HTTP is the opposite contract: the caller waits, and failure is the status code on that socket. A queue acknowledges the producer, then the consumer may lag, retry, or land in a dead-letter queue, and at-least-once delivery means the consumer must be idempotent. I did not operate Kafka, SQS, or SNS at internships, so this answer is CS, not a Ylogx bullet. Argus “automated alerts” and Ylogx “real-time KPI dashboards” are resume verbs, not named brokers. If they ask how dashboards were live, I describe polling versus WebSockets from the skills list and I do not invent a bus.

Example: producer key = orgId so one tenant’s SQL-RAG jobs stay ordered on one partition while other orgs run in parallel. HTTP report builder stays synchronous REST: the user waits for SQL. A Kafka retry of “send PPE alert” needs an idempotency key on event_id or the floor gets two SMS for one detection — still hypothetical; Argus logging was Postgres, not a named broker.

If they probe: “Global order?” no, not without one partition. “Exactly-once?” idempotent producer plus transactions — name it, do not lecture. “Did Ylogx use Kafka?” no.

This IE listed S3, NoSQL, sharding, Docker, EC2, and REST after a behavioral round without splitting the slot, so I give one honest breath. REST is how Ylogx exposed HTTP from FastAPI and NestJS. S3 is an object store for models or PDFs, not a place for RLS rows. NoSQL here means I skip joins: session or hot answers go to Redis, not a Mongo warehouse of 30 KPIs. Sharding is splitting a primary; I did not shard Ylogx, and one Postgres with RLS is what shipped. Docker and ECS are the intern compute path. I did not run EC2 by hand and I did not own a Kubernetes cluster; Kubernetes is skills-list only. CloudFront sits in front of ALB which sits in front of ECS, which is the path I can attach to 99.9 percent uptime and sub-210 ms. Facts stay in Postgres; Redis is the hot bot cache.

Example: browser → CloudFront → ALB → ECS task serving REST. Dashboard JSON is generated from Postgres under RLS; CloudFront may cache JS bundles, not tenant rows. A BRD PDF would live in object storage. Redis GET org+tier+qhash is the NoSQL hop that cut bot database latency 35 percent.

If they probe: “Why not Mongo for dashboards?” joins, transactions, RLS, SQL RAG. “Did you shard?” no. “k8s?” skills, not intern path.

LeetCode 8362604 is a behavioral follow-up about rate-limiting decisions and geofencing, not a second independent Rate Limiter design, so the live-round count stays one. If they use that phrase I tell one decision from resume work: who is limited, whether I fail closed or open, or a geographic constraint I actually faced, then I stop. I do not walk to the editor and implement a token bucket unless they explicitly switch into LLD. I will not borrow an Amazon retail geofence I did not ship. Ylogx authZ already fail-closes when RLS cannot be evaluated; that is the honest closed-door story. A cache miss fail-open to Postgres is the honest open-door story and is not a rate limiter.

Example: “On the BI bot we did not ship a limiter. The decision that looks like fail-closed is RLS: if the policy database cannot decide the org tier, we return no rows rather than a cached answer from another tenant. If they then ask me to design a limiter, I will, but that is a new prompt and still not Job 10454435.”

If they probe: “Code it.” only after they switch to LLD; then token bucket plus 429. “Is this UTA?” this BR is AUTA APAC 2026; Rate Limiter count still 1 and not UTA two-DSA.

The resume says caching reduced bot database latency by 35 percent; it does not say “cache-aside,” which is the CS name for the read path I actually describe. On GET I ask Redis for a key; on hit I return; on miss I query Postgres as the RLS role, SET the value with a TTL I will not invent a number for, and return. The application owns the fill, which is lazy loading. The key is tenant, role or tier, and a query fingerprint or schema hash, never raw natural language and never a key that is shared across the three organizational tiers. A cache hit that skipped RLS would be a leak scaled by that same 35 percent. On write or DDL I invalidate or rely on a short TTL; a stale dashboard tile is better than another org’s rows. If Redis is down I fail open to Postgres on this bot cache so analysis stays available and I give back the latency win. I never fail open RLS: if the policy cannot be evaluated, deny. Frugality is why I cached hot schema and repeat answers before buying a larger instance. I will not invent p99 traces. This is not Job 10454435 “caching layers,” and I will not claim write-through or write-back unless they ask the CS contrast.

Example: key orgA:tier2:sha256(normalized_sql). Miss → SET app.org_id → SELECT under RLS → SETEX. Builder publishes a new dashboard spec → UPDATE Postgres → DEL keys for that org and tier. Redis timeout → catch and load.get() from Postgres. RLS deny → do not write Redis.

If they probe: “Write-through?” extra write latency; not what I claim shipped. “Stampede?” lock or singleflight on miss — describe the failure, do not invent a shipped lock. “TTL?” resume does not name one.

CloudFront is a CDN: edge caches, TLS, and Anycast so a user hits a nearby point of presence instead of every ECS task. Static JavaScript, CSS, and Recharts bundles, plus cacheable GETs that are not tenant-specific, should not hit the origin every time. The origin chain is CloudFront to ALB to ECS tasks. DNS is GoDaddy as registrar, Route 53 for AWS routing, ALB as the layer-7 load balancer. Sub-210 ms is the resume-stated response time, not a load-test dump in the repo; I defend it as cache plus pooling, and I keep the LLM off the dashboard hot path. Frugality is CDN and Redis before a bigger box. If they wander into an indexing or host-header incident, I isolate CloudFront versus origin versus DNS versus ALB; I will not upgrade that into a named multi-region outage. Personalized RLS JSON and chat completions are not CDN objects. Redis remains the application cache next to ECS; CloudFront is off-box HTTP at the edge. GiftedBooks sub-300 ms and 99.5 percent is a different project.

Example: GET /static/dashboard.js is served from a CloudFront PoP with Cache-Control after deploy invalidation. GET /api/kpis bypasses the edge cache or uses a private cache, because the body is org-scoped under RLS. Bot NL answers live in Redis with org and tier in the key, not in CloudFront. Reports 40 percent faster is the Postgres report path, not “we cached tenant SQL at the edge.”

If they probe: “403 vs 502 vs 504?” CloudFront vs ALB vs origin timeout. “Origin shield?” not on resume. “Signed cookies?” not on resume. “99.9% from CloudFront alone?” no — ECS/ALB/CloudFront together, not WAL.

A reverse proxy sits in front of an origin and speaks HTTP for it: TLS, path rewrite, maybe a cache. A load balancer does that and also chooses among N healthy backends. On this resume the named hop is CloudFront to ALB to ECS. ALB is the layer-7 load balancer: health checks, host and path routing, spread across tasks. Nginx is on the skills list as a reverse proxy, TLS terminator, and static server; I will not invent a production Nginx hop in front of Ylogx. CloudFront is a CDN and a reverse proxy at the edge; it is not a substitute for ALB health checks on tasks. Sticky sessions would be the wrong fix for in-memory session state; a shared Redis is the better default, and Ylogx already used Redis as a cache, not as a session store I will invent. The Rate Limiter IE is why limiter state cannot live in a JVM HashMap: many app servers sit behind a load balancer.

Example: client → CloudFront (edge proxy + cache) → ALB (pick healthy ECS task) → FastAPI/NestJS. Nginx might sit in a side project as proxy_pass to port 3000; that is not the intern production path. If they ask L4 versus L7, ALB is L7; NLB would be L4 and is not named on the resume.

If they probe: “HAProxy?” Class C coaching, not an IE. “Did Ylogx use Nginx?” skills; named hop is CloudFront → ALB → ECS. “NLB?” not on resume.

The resume names ECS, ALB, and CloudFront; it does not print a multi-AZ configuration, a multi-region pair, or Route 53 failover records. ALB can spread targets across availability zones and ECS can run in more than one zone; I did not claim “multi-AZ” or “active-active us-east-1 plus ap-south-1,” and I will not claim it in the room. If an Arijit-style unnamed design asks single machine versus multi-AZ, I ask whether they want in-process, then I say the production path I shipped is ECS behind ALB and CloudFront, without a named multi-region. Ninety-nine point nine percent uptime is not three-AZ math I measured. CloudFront is a global edge, not “I ran the app active-active in two regions.” GiftedBooks 99.5 percent and sub-300 ms must not be merged with Ylogx 99.9 percent and sub-210 ms.

Example: honest board: one region, ALB in front of ECS tasks that may happen to sit in more than one subnet, CloudFront at the edge, Postgres as one primary I did not shard. I will not draw a second region with conflict-free replicated dashboards. If they force disaster talk, active-passive replica is a CS sketch, not a resume claim.

If they probe: “How many AZs?” I did not measure or print it. “RPO/RTO?” not on resume. “Route 53 failover?” not spelled out.

Ylogx report builder and SQL RAG were synchronous REST: the user waits for a SQL result, and Redis is a cache, not a work queue. Real-time KPI dashboards can be polling or WebSockets; WebSockets are on the skills list, the resume does not name them for Ylogx, and I will not invent Kafka, SQS, or SNS. Argus is a containerized pipeline over more than twenty cameras with Postgres logging and automated alerts; I describe it as synchronous unless they ask, and there is still no named broker. IQVIA Deep Research over 200+ sites is LangGraph agent time, not a message bus on the resume. A queue is for fan-out, spike smoothing, or work longer than an HTTP budget; it is not a silent substitute for a 429 on admission. At-least-once delivery would require an idempotent consumer, which I will name only if they push CS.

Example: POST /reports waits for Postgres and returns 200 with rows. A bot turn hits Redis then Postgres, still on the request thread. Argus: frame in, detection, INSERT event/alert, notify staff — no SQS on the resume. IQVIA: LangGraph nodes over 200+ sites, traced in LangSmith, still not SQS. If they ask what a queue would look like, 202 plus a job id, not a fake intern broker.

If they probe: “Why not queue SQL RAG?” user wants the answer now; timeout is the failure. “WebSockets for 30 dashboards?” possible; not a named Ylogx claim. “DLQ?” CS follow-up, not shipped.

Fail-open means a dependency is down and I still allow the user through; fail-closed means I deny. On the Ylogx bot cache, Redis down fail-opens to Postgres: analysis stays up, I lose the 35 percent latency win, and origin load rises. On authZ, if RLS or NestJS RBAC cannot decide the three-tier policy, I fail closed and return no rows, because a cache hit without a policy is a leak. I did not ship a rate limiter; the CS pick if they map it onto internships is fail-closed on money and fail-open on a pixel. Circuit breakers are a related word: after N failures I stop calling the dependency, and I still have to say whether the user is allowed or denied. I pick from their entity rather than reciting a blog.

Example: Redis timeout on GET orgA:tier2:qhash → catch → query Postgres as RLS role (open). Postgres or GUC missing → no SELECT, 403 or empty (closed). Checkout limiter with Redis down → 429 (closed). Marketing pixel limiter with Redis down → 204 (open).

If they probe: “Circuit breaker open vs fail-open?” breaker open means stop calling Redis; user-facing open or closed is a second choice. “Fail-open RLS?” never.

CAP says that when a network partition happens, a distributed store chooses linearizable consistency or availability for that partition; partition tolerance is not optional once you have more than one node. CP in talk-track is a Postgres primary with a synchronous replica that refuses a stale read if it cannot see the primary. AP in talk-track is DNS, a CDN, or a cached catalog where stale is OK. Ylogx Postgres plus RLS is the source of truth and leans C for tenant rows. Redis and CloudFront are AP-ish for hot reads: TTL and invalidation, not linearizability. I will not say “we picked AP for the whole app.” PACELC is the extra sentence if they push: even without a partition you still trade latency versus consistency, and a cache is the latency choice. I will not draw a twelve-service CAP diagram for Arijit unnamed design unless they asked distributed. Dynamo is a lecture I skip unless they name it.

Example: two ECS tasks, one Redis, one Postgres primary. During a blip Redis may serve a one-TTL-stale KPI answer (A over C on the cache copy). The dashboard row itself commits on Postgres; a replica that cannot see the primary does not invent a row for another org (C over A on the source of truth). CloudFront may serve yesterday’s JS bundle; that is fine. CloudFront must not serve org B’s JSON to org A.

If they probe: “Is Postgres CP?” the primary plus sync replica talk is CP; a lone primary is not a distributed CAP diagram. “Is Redis AP?” the copy can be stale; SoT stays Postgres. “CAP for Arijit?” only if they asked distributed.

A reverse proxy is the process the client talks to, which then talks to one logical origin: TLS, auth, cache, path rewrite. Nginx, Caddy, and CloudFront-as-origin-facing are reverse proxies. A load balancer is a proxy that also chooses among N backends with round-robin, least-connections, IP-hash, or health checks. ALB and NLB are AWS load balancers; HAProxy notes from coaching dumps are not interview evidence. Layer 4 is TCP or UDP, which is NLB territory; layer 7 can read HTTP headers, which is ALB. Sticky sessions keep a user on one task because session state is in memory; I prefer shared Redis over stickiness, and I will not invent a Ylogx session store. The Rate Limiter IE is the concrete reason a JVM HashMap is wrong: many app servers sit behind a load balancer, so two tasks would each admit a full budget.

Example: three ECS tasks, ALB health checks every 30 seconds, round-robin. Token bucket in each JVM would admit 3× N requests. Redis Lua behind the same ALB admits N. CloudFront in front is still a reverse proxy at the edge and does not replace those health checks.

If they probe: “L4 vs L7?” TCP vs HTTP headers. “IP-hash?” sticky by client IP, still worse than shared state for a limiter. “Nginx on Ylogx?” skills, not the named hop.

Cache-aside, or lazy loading, means the application reads the cache, loads the database on miss, and writes the cache itself. That is the Ylogx bot path: read-heavy, TTL-tolerant, and filled only after an RLS query succeeds. Write-through means every write updates database and cache together so reads can always hit the cache, at the cost of extra write latency, which I do not claim shipped. Write-back means the cache is the first write and the database flushes later, which is fast and can lose data on crash unless there is a WAL; it is the wrong story for BI and RLS. A stampede is many misses on one key; the CS mitigation is a lock or singleflight plus TTL jitter, which I will describe without inventing a shipped lock. Unauthorized rows must never enter the cache, which is why the key includes org and tier and why an RLS deny does not SET Redis.

Example: aside: GET redis → miss → Postgres as RLS role → SETEX. Write-through would UPDATE dashboard spec and SET the cache in one app step. Write-back would SET Redis and flush Postgres later — a crash could lose a dashboard spec, which I will not propose for tenant BI. On miss storm for a hot org, one task loads Postgres and the others wait; jitter keeps TTLs from aligning.

If they probe: “Which did Ylogx ship?” aside is the honest CS label; resume says caching, not the other two. “Write-back for reports?” no — durability of dashboards is Postgres.

A CDN caches GET and HEAD at points of presence, optionally with an origin shield I will not claim. Cache-Control and Vary decide what can be stored; a deploy invalidates or versions the asset. Personalized RLS rows, POST bodies, and chat completions do not belong at the edge. CDN the static assets and public GETs; tenant SQL stays at origin plus Redis with tenant keys. Redis is an application cache next to ECS; CloudFront is off-box HTTP at the edge; Ylogx used both, and they are not the same layer. Sub-210 ms is the resume response time from cache plus pooling, not an LLM on the KPI GET. I will not invent origin shield or signed cookies that are not on the resume.

Example: CloudFront caches /assets/recharts.js for the 30 KPI dashboards. Redis caches orgA:tier1:schemahash for the bot. A POST that generates SQL RAG is neither. After CI/CD, invalidate the JS path or use hashed filenames so ECS does not serve mixed bundles.

If they probe: “Can CloudFront cache API JSON?” only if it is public and not tenant-scoped. “Origin shield?” not on resume. “99.9%?” service uptime of the whole path, not CDN alone.

Synchronous HTTP means the caller waits until success or timeout; a retry can duplicate a side effect, so money and shipping need idempotency keys. Asynchronous means the producer gets an ack, work sits in a backlog, consumers scale independently, poison messages go to a dead-letter queue, and ordering is per partition if they bring up Kafka. The user typically gets 202 and an id, not the final row. Queue when you need fan-out, spike smoothing, or work longer than an HTTP budget. IQVIA research over 200+ sites is agent time, still not a named SQS on the resume. A Rate Limiter reject is 429, not “enqueue the user’s checkout and hope.” You may queue a background job; you do not replace the admission decision with a queue unless they asked for a leaky-bucket delay. I did not operate a broker at internships.

Example: checkout over budget → 429 plus Retry-After, not SQS. Argus alert SMS, if they ask async, would be 202 plus an alert id and an idempotent consumer on event_id — still not a named intern broker. SQL RAG stays sync because the analyst is waiting. LangGraph Deep Research is long-running agent orchestration, not a message bus I will invent.

If they probe: “At-least-once vs at-most-once?” at-least-once plus idempotency is the usual honest pair. “Kafka at Ylogx?” no. “Leaky bucket as delay?” only if they asked to smooth rather than reject.

When Redis, an auth store, or a feature-flag service is down, fail-open allows the request and risks melting the origin; fail-closed denies and protects the origin or a safety invariant, at the cost of false negatives. Safety, money, and authorization go closed. Telemetry, ads, and an optional cache go open. A circuit breaker after N failures stops calling the dependency; that is closed toward the dependency, and I still say whether the user is allowed. The Rate Limiter IE expects this fork when Redis is down: closed on checkout, open on a pixel. On my resume the same fork is Redis cache open to Postgres versus RLS closed if policy cannot be evaluated.

Example: limiter Redis timeout on POST /checkout → 429 (closed). Limiter Redis timeout on a beacon → 204 (open). Ylogx Redis timeout on bot GET → Postgres (open). Missing app.org_id GUC → no rows (closed). Feature flag service down for a cosmetic theme → default theme (open); down for “may this org see payroll” → deny (closed).

If they probe: “Which for Arijit unnamed?” pick from their entity, do not default to Redis. “False 429s OK?” on payments, yes, rather than unlimited checkout.

HTTP 429 means Too Many Requests: this client exceeded a policy. Retry-After is seconds or an HTTP-date until the client should retry. A silent drop hides the policy and makes honest clients hammer harder. 503 plus Retry-After means this server is overloaded or in maintenance; 429 means you, the caller, exceeded quota, and I will not mix them. The body may be problem+json and must not leak whether an API key exists. Idempotent GET retry is fine; POST needs an idempotency key or you double-charge. The limiter returns remaining window or time-to-next-token as Retry-After from middleware, not from each business service. I did not ship this at internships; the Java sketch is the token bucket plus those headers.

Example: HTTP/1.1 429 Too Many Requests with Retry-After: 1 when the token bucket has 0.4 tokens and refill is 1 per second. Do not return false with 200. Do not 503 unless the ECS task itself is sick. Checkout POST carries Idempotency-Key so a retried 429-then-success does not double-charge.

If they probe: “429 vs 403?” 403 is authZ; 429 is quota. “429 vs 503?” policy vs this server is sick. “Date vs delta in Retry-After?” both legal; seconds is simpler on a token bucket.

An availability zone is an isolated data center inside a region, with separate power and network. Multi-AZ load balancing plus a database standby survives losing one zone; RPO and RTO are still not zero because failover takes time. Multi-region is for latency and disaster: active-active brings write conflicts, active-passive brings replication lag, and CAP shows up for real. ECS and ALB on my resume are not a named multi-region. CloudFront is a global edge cache, not “I ran the app active-active in two regions.” I will not derive 99.9 percent from an AZ count I did not measure. GiftedBooks 99.5 percent stays on that project.

Example: CS sketch if they insist: ALB with targets in two AZs, Postgres primary in AZ-a and a standby in AZ-b, CloudFront at the edge. I label it a sketch. I do not add ap-south-1 plus us-east-1 with conflict-free dashboard specs as something I shipped.

If they probe: “RPO zero?” not with async replica. “Active-active RLS?” conflict on org rows — I will not claim it. “Is CloudFront multi-region app?” no, it is edge.

interface RateLimiter { boolean allowRequest(String key); }

final class TokenBucketRateLimiter implements RateLimiter {
    private final int capacity;
    private final double refillPerSec;
    private final Map<String, Bucket> buckets = new HashMap<>();
    private final Object lock = new Object();
    static final class Bucket { double tokens; long lastNanos; }
    public boolean allowRequest(String key) {
        synchronized (lock) {
            long now = System.nanoTime();
            Bucket b = buckets.computeIfAbsent(key, k -> {
                Bucket x = new Bucket(); x.tokens = capacity; x.lastNanos = now; return x;
            });
            b.tokens = Math.min(capacity, b.tokens + (now - b.lastNanos) / 1e9 * refillPerSec);
            b.lastNanos = now;
            if (b.tokens < 1) return false;
            b.tokens -= 1;
            return true;
        }
    }
}

V get(String tenantKey, String cacheKey, Supplier<V> load) {
    V hit = redis.get(tenantKey + ":" + cacheKey); // never drop tenant from the key
    if (hit != null) return hit;
    V v = load.get(); // Postgres as RLS role
    redis.setex(tenantKey + ":" + cacheKey, ttlSec, v);
    return v;
}

This is Shiwangi’s UTA OOD for counting a word in a specific book, mapped as our R3 analogue, not Amazon retail HLD and not a Job 10454435 prediction. I clarify one book versus a catalog, case folding, punctuation, title versus body, and whether we scan at query time or precompute. Entities stay small: Book with isbn, title, and a frequency map, plus Bookstore as a catalog; I do not dump inventory and payments onto Book. The APIs they wanted named are add a book, count a word in a book by isbn, and count on the Book itself. The data structure is a HashMap from word to count built in the constructor by splitting on non-word characters and lower-casing, so query is average O(1) and build is O(tokens). If they ask which books contain a word, I add an inverted map from word to isbn counts. One in-memory map per book is enough for Live Code. Phrase count needs token arrays, not only frequencies. A concurrent new edition replaces the Book object under the isbn key rather than mutating mid-query without a lock. If I stall I write Book with the map in the constructor and count(word).

Example: add Book isbn 111, body “The cat sat on the mat.” After tokenize, freq has the→2, cat→1, sat→1, on→1, mat→1. countInBook("111", "the") returns 2. I do not design Amazon.com search, recommendations, or checkout around this prompt.

If they probe: “Phrases?” store tokens, scan for adjacent words. “Thread safety?” replace the Book, or lock the map. “Which books contain X?” inverted index, only if they ask.

Two independent IEs asked the same locker-and-package family in different slots, not two products, and neither is UTA or AUTA, and neither is Job 10454435. I clarify Hub Locker versus warehouse cubby, one package per cubby, assign versus customer-choose, code expiry, and single versus multi-site. Entities are locker size, package, locker with occupy and release plus access code, site, and a smallest-fit strategy. APIs: dropOff returns an access code, pickUp returns the package id after code check, addLocker, and pick on the strategy. Data structures are HashMaps for id lookup and an EnumMap of deques of free lockers so smallest-fit is O(1) at the head of the right deque. If they name scale, as Uday did, I shard by site prefix, persist occupancy, and assign with a conditional write so two couriers cannot win one cubby; free-counts per size are a cache of counts, not the source of truth. UX is SMS with map and code, oversized to an associate, expired code regenerated after ID check, and a TTL plus compensation if the courier crashes after occupy. Site depends on a strategy interface; there is no god service. If I stall I draw Site, Locker, Package and implement dropOff then pickUp.

Example: package needs M. Free deques: S has two, M has one. Strategy takes M’s head, occupies, stores a six-character code. pickUp with wrong code fails; with right code releases and returns the locker to the M deque. Two couriers: SQL UPDATE locker SET occupied = true WHERE id = ? AND occupied = false so one wins. I do not open with Redis because a blog said caching.

If they probe: “UX?” SMS, map, oversized path, expiry. “Scale?” site shard and conditional occupy, only if they asked. “Cache the lockers?” cache free-counts, not occupancy truth.

Parking Lot OOD showed up on a GFG fresher R2 after tree and interval DSA, and similar-family sets later; DevBrainiac’s experienced R3 is not a second UTA ask. I clarify vehicle versus spot types, multi-floor, hourly versus flat, and I add EV or reserved only if they do. Entities are Vehicle, ParkingSpot, Ticket, ParkingLot, and a pricing policy. APIs: enter returns a ticket or null if full, exit returns cents, addSpot. Data structures are a HashMap of spots, an EnumMap of free deques for first-fit, and openTickets for O(1) exit. Multi-floor means a Floor owns free maps and the lot picks a floor with a fit; locking can be per lot or per floor. Taanya’s “LLD similar to parking lot” with an interval stream is the same family plus sweep-line or min-platforms if they ask how many spots are needed or whether the lot is full at time t; it is not a second unique Parking Lot count. If I stall I write Vehicle, Spot, Ticket, enter and exit, and price last.

Example: car enters, first-fit car deque pops a spot, Ticket stores spotId, plate, inEpochMs. Exit looks up the ticket, frees the spot, HourlyPricing.cents(in, now). Full lot returns null rather than a wait queue unless they ask. Interval follow-up: events [in, out) sorted, scan occupancy, max is spots needed.

If they probe: “Bus in car spot?” type rules on the spot. “Wait queue when full?” only if they add it. “Is Taanya a second ask?” no, similar-to, same family.

Prince’s R2 asked a playlist with insert, delete, and search in average O(1), same loop as locker R1, not UTA. Related song-album and flexible-playlist posts are family, not this card; GetRandom O(1) is a different IE. I clarify unique names, insert at end versus index, exact versus prefix search, and one playlist versus a library. Entities are SongNode with prev and next, and Playlist with dummy head and tail plus an index. APIs: insert at end, delete by name, search exact; I do not claim O(1) insert-at-index in an array. The structure is HashMap from name to node plus a doubly linked list for play order, the same pattern as LRU, average O(1). TreeMap is O(log n) ordered iteration and I refuse it if they demanded O(1). One playlist is in-memory; “Spotify-scale” is not this question. Duplicates use name#id plus a secondary set. Next and prev walk the list. One lock on the playlist if they ask threads, because splicing is not lock-free homework. If I stall I search first with the HashMap, then add the list for order.

Example: insert “Imagine”, “Hey Jude”, “Imagine” again if names must be unique returns false. delete “Hey Jude” unlinks the node in O(1) via the map. search “Imagine” is containsKey. I do not build a music catalog of albums unless they switched to that family card.

If they probe: “Insert at index i?” that is O(n) walk or a different structure; do not claim O(1). “Prefix search?” not this API. “GetRandom?” different IE, ArrayList plus map.

Unix find and a Java library to search files by constraints are one family: Vanshika’s find-like, Raghav’s high-level library, with US Levels.fyi size-name-type-date-empty as NMF evidence, not a second India UTA ask. Pratyush’s in-memory file library is a cousin with Composite and Visitor, not this card. I clarify real filesystem versus in-memory, AND versus OR, symlinks, permission errors, and whether we return paths or objects. Entities are PathPredicate specifications, concrete NameGlob, TypeFile, MinSize, AndPred, FileFinder, and a LinuxFileSearch façade. The API is find or search from a root with a predicate whose test sees Path and attributes. Data structure is a DFS or BFS walk, Files.walkFileTree, AND-composed predicates, no Trie unless they ask prefix over millions of already-indexed names. Scale means stream the walk, do not load the tree; parallel partition of top-level dirs is usually overkill; predicates stay immutable. Cycles need a visited set of directories on the in-memory cousin. Empty file is size zero and date is lastModifiedTime on the US NMF list; I will not stamp that list on Vanshika unless she listed them. If I stall I AND name and size and wrap LinuxFileSearch.

Example: find(root, new AndPred(new NameGlob("*.log"), new MinSize(1_000_000))) walks from root and collects paths that match both. I do not design SNS, S3 inventory, or a 40-minute AWS search product around this prompt.

If they probe: “OR?” compose OrPred. “Symlinks?” ask follow or not. “Trie?” only for prefix over an index they asked for. “Vanshika’s exact flags?” do not copy the US NMF list onto her.

Nitesh’s R2 was LLD similar to a notification system plus unnamed GenAI, not a full SNS, SES, or Pinpoint design, and not Job 10454435. I clarify in-process Observer versus email SMS push, sync versus queue, templates, opt-out, and at-least-once versus at-most-once. Entities are Notification, ChannelType, NotificationSender implementations, PreferenceStore, and NotificationService. APIs: notify, send on the sender, allows on prefs, and optional offer onto a queue if they ask async. Data structure is an EnumMap from channel to sender, plus an optional BlockingQueue and worker. I do not draw a topic-partitioned broker unless they push scale, and then one minute: enqueue, workers per channel, idempotency key, backoff and DLQ, stop, no AWS logos unless they ask cloud. DoS is a per-user cap in the elevator style, not a second Rate Limiter count. If I stall I write Notification, Sender, Email, SMS, and notify that picks by channel. Argus alerts are a resume analogue only if they pivot to my work.

Example: notify(new Notification(userId, "PPE", "no helmet", SMS)) checks prefs.allows, then senders.get(SMS).send(n). Overload: offer onto a queue, worker sends, idempotency key event_id so one detection is one SMS. I do not design Pinpoint.

If they probe: “Fan-out to three channels?” loop senders that prefs allow. “GenAI?” unnamed on that IE — do not invent a prompt. “Is this Rate Limiter?” no; count stays 1.

Nisarg’s AUTA R2 was LP plus LLD for dog check-in and check-out tracking; the candidate said tracking, and I will not invent Amazon Pets or a campus kennel product. I clarify one active visit versus history, breed or size limits, and concurrent kiosks. Entities are Dog, Visit with out null while open, KennelStore, and KennelService with capacity and occupancy. APIs: checkIn, checkOut with ownerId, plus store save, get, openVisit, history. Data structures are a HashMap from dogId to open Visit, an occupancy counter, history lists, and optionally a min-heap of open visits by in-time for overdue. Live Code uses one lock. Crash mid check-in: persist first then increment, or one transaction. Swap InMemoryKennelStore for JDBC later (open-closed). CapacityPolicy can appear later; Daycare is not Dog. Guards: unknown dog, already in, full, owner mismatch. If I stall I write Dog, Visit, checkIn and checkOut with already-in and full.

Example: checkIn("d1") when occupancy is at capacity throws full. checkIn("d1") again while open throws already in. checkOut("d1", wrongOwner) fails. checkOut("d1", owner) sets outEpochMs and occupancy--. I do not add pet-store retail, inventory, or Amazon.com around this tracking prompt.

If they probe: “History?” list of closed visits per dog. “Concurrent kiosk?” one lock on the service for Live Code. “Amazon Pets?” candidate said tracking only.

Kamlesh was asked to design a Q&A platform similar to Stack Overflow as entities, models, and data structures, not a full HLD of Stack Overflow, not UTA, not Job 10454435. I clarify comments, reputation rules, auth, and whether in-memory is OK. Entities are User with reputation, Tag, Post, Question extending Post with title tags and acceptedAnswerId, Answer extending Post with questionId, VoteService, QaStore. APIs: addQuestion, addAnswer, byTag, vote, and accept which sets acceptedAnswerId for the question author only, one accepted. Data structures are HashMaps by id, answersByQ, a tag inverted index from slug to question ids, and a vote dedup set of userId|postId. Full-text search is one sentence about a later inverted index; I do not put Elasticsearch on Post. Scale is not this 45-minute sketch; if they insist I shard questions by id, treat the tag index as the hot read, and keep votes idempotent with that set. If I stall I write User, Question, Answer, Tag, Vote, HashMap store, addQuestion, addAnswer, byTag. GiftedBooks is a resume analogue only if they pivot to my PDF Q&A, and I will not mix AegisAI’s README into that product.

Example: addQuestion with tags java, sql → append questionId to both inverted lists. addAnswer links into answersByQ. vote(u, post, +1) fails the second time because user|post is in the set. accept is one acceptedAnswerId. I do not draw CDN, Kafka, or Amazon retail search.

If they probe: “Reputation?” one sentence, not a 20-minute subsystem. “Search?” later inverted index / ES, not on Post. “Your product?” GiftedBooks ingest plus ask(docId, question) only if they asked.

This is the same independent SDE I Rate Limiter as above, restated in product-LLD shape: entities and APIs they would make you name after they named the product. Independent live-round count stays one, OA-plus-three, not UTA two-DSA, not a second ask from YouTube or SDE II Super Day, not Job 10454435. Entities are RateLimiter with allowRequest, TokenBucketRateLimiter, SlidingWindowCounterRateLimiter, and a RateLimitFilter in middleware. APIs: allowRequest, and preHandle that returns null if allowed else Retry-After seconds; reject is HTTP 429, not a silent drop. Single-box DS is a HashMap of buckets plus one lock. I write token bucket and sketch sliding counter; I name fixed window, sliding log, and leaky bucket without coding all five. Distributed means Redis plus atomic Lua so GET-refill-DECR-SET cannot race across app servers. Fail closed for checkout, fail open for a pixel. Clock is monotonic locally and Redis TIME inside Lua. Multi-limit is AND of per-user and global. If I stall: allowRequest, token bucket in HashMap, same math in Lua, 429 plus fail-closed. Elevator DoS “rate limit the kiosk” is a different card’s security follow-up.

Example: filter in front of checkout: key = userId + route, capacity 10, refill 10/s. Lua returns 0 → 429 Retry-After 1. Three ECS tasks cannot each admit 10. Redis down on checkout → deny. I still do not claim I shipped this at Ylogx; Redis there cut bot DB latency 35 percent as a cache.

If they probe: “Sliding counter?” Cloudflare/Kong-style buckets. “Hot key?” mention shard, do not novel-design. “Is this UTA?” no. “Job 10454435?” still no public named live SD.

Arijit’s prompt is unnamed, so this card is questions I ask them, not a product I invent. I will not open with caching, API gateway, locker, Rate Limiter, or CampusToCareer “APIs, databases, caching layers” as what he or Job 10454435 asked. I ask the user-facing verb, read versus write or whether single box is fine, entities and ids, whether a read may be one second stale, single machine versus multi-AZ, what must not double-charge or double-ship, and which APIs they want named as proposals until they nod. After they name a domain, placeholders are create, get, update on FooService and a ConcurrentHashMap, four to six boxes, client app store. Timebox: restate, entities they named, one deep slice, 10× only if they asked scale on that entity, one failure and one metric. If stuck I list entities, the happy-path method, and the axis. Resume stack comes only after they nod at a BI or chatbot domain.

Example: they say “track packages at a site.” I still do not paste the locker card unless they named lockers. I propose Package, Site, dropOff/get, in-memory map, and wait. If they later say “like your dashboards,” I switch to Ylogx REST, Postgres, Redis, CloudFront, ALB, ECS, RLS three tiers, and only then sub-210 ms or 99.9 percent if they ask what shipped.

If they probe: “Start with Redis.” I ask if stale reads are OK. “Draw Amazon retail.” they did not name it. “Is the prompt lockers?” unnamed — do not guess.

Amazon did not ask GiftedBooks; this is a resume-derived analogue to Kamlesh’s Q&A entities if they pivot to my product. Entities are an uploaded PDF, chunks, a query, and a grounded answer, not a general chatbot. APIs I would name if they ask this product: ingest a PDF, and ask(docId, question) returning an answer under the latency SLO. Retrieval is vector or keyword over the student’s material, which the resume calls RAG. The giftedbooks README currently describing AegisAI is a mismatch; the resume is authoritative and I will not mix those codebases. Scale numbers I may use: API sub-300 ms, suite 99.5 percent uptime, doubts that took hours now 3–10 minutes, plus 35 percent reading, plus 50 percent engagement, 2.5× comprehension. I will not invent student headcount. This is not IQVIA Azure Search, not LangSmith, and not Ylogx SQL RAG. FAISS is skills and GiftedBooks-scale talk, not a library name I will stamp on the bullet if the bullet does not name it.

Example: ingest splits a lecture PDF into chunks, embeds once, stores vectors. ask(docId, “what is 3NF?”) retrieves top-k chunks from that doc only and generates a grounded answer inside 300 ms. I do not attach IQVIA’s 200+ page BRDs or Ylogx RLS to this store.

If they probe: “AegisAI?” README mismatch; GiftedBooks is resume only. “Headcount?” do not invent. “FAISS on the bullet?” confirm; skills list has FAISS, the bullet says RAG.

This is a resume scale story after they named a scale axis, not an opener for unnamed system design, and not CampusToCareer caching layers for Job 10454435. Entities are org-scoped BI rows, a chatbot turn, and a cache key. APIs are natural language to SQL RAG over Postgres, plus reports. Isolation is RLS plus RBAC for three organizational tiers, not a UI hide. What shipped: Redis cut bot database latency 35 percent, reports 40 percent faster, sub-210 ms, 99.9 percent uptime, ALB, ECS, Docker, CloudFront, SQL RAG plus 65 percent analysis productivity, 30 KPI dashboards plus 60 percent ops. The 10× bottleneck I would name if they ask is the bot hammering Postgres with repeat NL and schema reads, which is why cache-aside on org-plus-tier keys came before a larger instance. Fail-open Redis to Postgres; fail-closed RLS. Internships were FastAPI, NestJS, and Postgres; Live Code is Java; I say that once. I do not invent SQS or Kafka on this path.

Example: 10× chatbot QPS, same 30 dashboards. Without cache, each turn hits Postgres for schema and a generated SELECT. With cache-aside, hot answers hit Redis keys that include org and tier; misses still run as the RLS role. CloudFront still serves Recharts bundles so ECS does not. LLM stays off the KPI GET so sub-210 ms remains plausible.

If they probe: “Open with Redis on unnamed SD?” no. “Shard Postgres?” I did not. “99.5%?” that is GiftedBooks, not this project.

Amazon did not ask Argus; this is a resume analogue to Nitesh’s notification-like LLD if they pivot to alerts, not SNS homework. Entities are a camera stream, a detection, and an alert to floor staff. APIs: ingest a frame, detect, notify; Postgres logs events and alerts. Scale I can say: more than twenty cameras, 24 FPS, 15,000+ images, mAP 73 to 89 percent, violations down 50 percent, compliance 2×. I log events, not a row per frame, because 20 times 24 is about 480 frames per second. Notification is a Sender interface if they want the LLD slice; I still do not invent SQS. Pixels go to object storage if they ask; Postgres is the audit join. I will not invent README routes that 404.

Example: detect no-helmet at CAM-07 → INSERT event plus alert in one transaction → notify(SMS) if prefs allow, idempotent on event_id. Floor query joins alert to event to camera for open status. I do not put JPEGs in the primary key.

If they probe: “Broker?” not named. “Ylogx RLS on cameras?” skip unless they ask; this was logging. “24 FPS into Postgres?” events, not frames.

Low-level design at SDE I is classes, three compiling APIs, and an in-memory HashMap. High-level design is load balancers, queues, and multi-AZ, and I add it only if they push scale, with one bottleneck and one mitigation. I do not dump a cache or locker template onto an unnamed prompt. Bookstore word-count, playlist O(1), and dog check-in are LLD. Rate Limiter becomes HLD when they say distributed. Arijit unnamed stays LLD until they ask an axis. Ylogx CloudFront and ALB are resume HLD I bring only after they named a domain that matches.

Example: Parking Lot enter/exit with deques is LLD. “What if ten floors and a million cars?” one sentence: shard by floor, one lock per floor — that is the HLD slice, not a 12-box retail site.

If they probe: “Start with CDN.” only if they asked scale or named HTTP assets. “Is Job 10454435 HLD?” still no public named live SD.

A cache is allowed when a stale read is acceptable for that get. If every read must be linearizable, the cache is not the design; a later replica might be. Locker free-counts are a cache of counts, not occupancy source of truth, which is why two couriers still need a conditional occupy. Ylogx Redis was measured at minus 35 percent bot database latency after RLS was correct, not instead of RLS. I never lead Arijit unnamed design with Redis. CDN is the other cache: assets yes, tenant JSON no. Write-back is the wrong cache for dashboard specs.

Example: getReport(id) may be one TTL stale → cache-aside with org in the key. dropOff(package) occupancy must not be stale → database conditional write, maybe cache the integer free-count for UX.

If they probe: “Cache authZ?” never skip RLS. “Cache POSTs?” no.

ArrayList search and delete are linear. A HashMap gives average O(1) lookup by name. A doubly linked list lets you splice O(1) once you hold the node. Together they are playlist insert-delete-search and LRU. TreeMap is O(log n) if they wanted ordered iteration, and I refuse it if they demanded O(1). I do not use an array and claim O(1) delete of an arbitrary song.

Example: Playlist map name → SongNode, dummy head/tail. delete(“Hey Jude”) finds the node in the map and unlinks prev/next. LRU from Bhavya is the same two structures with eviction at the tail.

If they probe: “Worst case HashMap?” O(n); say average, mention tree fallback if they push. “Insert at index?” walk the list, not O(1).

When Redis or a locker database is down, fail-open allows the user and risks overload; fail-closed denies and protects the origin, which can mean false 429s or no drop-off. I pick from their entity: payments closed, pixel open, RLS closed, bot cache open to Postgres. I say the trade-off out loud instead of reciting a default. Circuit breaker is stop-calling-the-dependency, then a second choice for the user. Ylogx already has both forks: Redis down still answers from Postgres, and a missing RLS GUC returns no rows. I did not ship a limiter; if they map the IE onto internships I still pick closed for money.

Example: locker DB down → do not dropOff (closed) rather than double-assign a cubby. Bot Redis down → query Postgres (open). Checkout limiter Redis down → 429 (closed).

If they probe: “Why false 429s?” better than unlimited checkout. “Fail-open occupy?” two packages in one cubby — no.

Idempotency means a retried write does not apply twice. dropOff, vote, checkIn, and allowRequest all need it. I name the key rather than drawing Kafka unprompted. Vote uses a set of userId plus postId. Locker assign uses a conditional occupy. Rate limiter uses atomic refill and decrement. Notification uses an idempotency key such as event_id. HTTP POST without a key can double-charge if the client retries after a lost 200.

Example: courier retries dropOff after a timeout: UPDATE locker SET occupied=true WHERE id=? AND occupied=false returns 0 rows the second time, same access code returned from the already-occupied row for that packageId. Argus alert SMS key = event_id so one detection is one message.

If they probe: “GET idempotent?” yes by HTTP. “Kafka?” only if they asked a broker.

Single responsibility: Locker occupies, LockerSite indexes, Daycare is not Dog. Open-closed: a new assignment strategy, sender, find predicate, or pricing policy should not edit the service. Liskov: strategy implementations are substitutable. Interface segregation: no AmazonGodService. Dependency inversion: the service depends on a store or strategy interface. The AUTA logger round grades this explicitly; I apply the same breath to any product they named.

Example: NotificationService holds Map<ChannelType, NotificationSender> and never if (email) … else if (sms). ParkingLot depends on PricingPolicy so HourlyPricing can become a weekend rate without editing enter/exit.

If they probe: “Show OCP on find?” add MinSize without editing FileFinder. “God class?” split Site and Locker.

The Rate Limiter IE rejects with 429 and Retry-After, not a silent drop and not 503 unless this server is actually sick. Notification overload queues with a dead-letter, because silently dropping a payment SMS is the wrong failure. Elevator DoS caps hall-calls; that is a security follow-up on elevator, not a second independent Rate Limiter. Queue the background job; do not enqueue checkout admission unless they asked for leaky-bucket delay. Honest clients need Retry-After so they back off instead of hammering. 403 is authorization, 429 is quota, and I will not mix those either.

Example: token bucket empty → 429 Retry-After 1. Alert worker down → queue plus DLQ, retry with event_id. Hall-call spam → cap per kiosk, still count=1 on the limiter card.

If they probe: “Silent drop for bots?” still prefer 429 so honest clients back off. “503?” origin sick, not quota.

// Book: Map<String,Integer> freq; split \\W+, toLowerCase; count(word) = getOrDefault
// Bookstore: Map<isbn, Book>; countInBook(isbn, word)

// EnumMap<LockerSize, Deque<Locker>> freeBySize; HashMap id→Locker, pkg→lockerId
// dropOff: smallest-fit deque head, occupy + 6-char code
// pickUp: release(code), return to free deque

// enter: first-fit free Deque, Ticket in openTickets
// exit: remove ticket, leave spot, pricing.cents(in, now)

// HashMap<String, SongNode> + dummy head/tail DLL
// insert end / delete by name / containsKey — average O(1)

// interface PathPredicate { boolean test(Path p, BasicFileAttributes a); }
// Files.walkFileTree + AndPred(NameGlob, MinSize)

// EnumMap<ChannelType, NotificationSender>; prefs.allows then senders.get(ch).send(n)

// checkIn: unknown / already-in / full guards; occupancy++
// checkOut: ownerId match; set outEpochMs; occupancy--

// questions by id; answersByQ; questionIdsByTag; VoteService Set user|post

interface RateLimiter { boolean allowRequest(String key); }
// HashMap<key, {tokens, lastNanos}>; refill min(capacity, tokens + dt*rate); tokens>=1
// distributed: Redis Lua atomic; 429 + Retry-After; fail-closed vs fail-open

interface FooService { FooId create(CreateFooRequest r); Foo get(FooId id); void update(FooId id, UpdateFooRequest r); }
// InMemory: ConcurrentHashMap<FooId, Foo> — not a claimed 10454435 API