3. Networking and backend

DNS turns a hostname into an IP so a client can open a socket. The first lookups hit the stub: browser cache, then OS cache, then a recursive resolver (ISP, VPC, or public). On a cache miss the recursive server walks root, then TLD, then the zone’s authoritative nameservers, and the answer is usually an A or AAAA, sometimes via CNAME or an AWS Alias. Java InetAddress.getByName is only that stub call on the JVM and OS; it is not a recursive server you wrote. TTL is why a wrong nameserver or a stale record can look like an outage while ECS is healthy. If they still ask classful A/B/C from that 2020 round, recite the ranges, then say the internet is CIDR and name the private blocks. On this resume GoDaddy is the registrar and Route 53 is the hosted zone; those are different jobs. Records then point at CloudFront or the ALB in front of ECS. This GFG prompt is older CN, not a Job 10454435 live question.

Example: User types the Ylogx hostname. GoDaddy NS records delegate to Route 53. Route 53 Alias A answers CloudFront or the ALB. CloudFront fetches origin through the ALB to an ECS task. Whiteboard Java is still InetAddress.getByName("example.com").

If they probe: www versus apex (Alias versus CNAME limits on apex); Alias to ALB versus CloudFront; A versus AAAA; stale TTL after a cutover; registrar is not the DNS host.

MAC is a link-layer address, typically 48 bits, unique on a broadcast domain; switches forward frames with it. ARP maps an IPv4 address to a MAC on the local LAN so the next hop can be addressed. IP is a network-layer address that is assigned and routed across networks; routers strip the Ethernet header and write a new next-hop MAC. NAT rewrites IP and ports; the MAC never leaves that hop. In one packet, Ethernet MACs change every hop while IP source and destination stay until NAT. Java NetworkInterface.getHardwareAddress is the local NIC, not the destination MAC, and there is no portable “get dest MAC” API that belongs here. I will not invent an ARP configuration story at Ylogx. The interview is the layering.

Example: An ECS task in a private subnet sends to the ALB. On the subnet the Ethernet destination is the gateway or target MAC from ARP. After the router that MAC is gone and a new one is used. Users on the internet never see the task MAC or private IP.

If they probe: DHCP hands out IP, gateway, and DNS, but the switch still needs MAC to deliver the frame; VPN and tunnels encapsulate L3 so inner MACs are not the path; spoofing exists, so uniqueness is not a security control.

The spoken walk is DNS, then a TCP three-way handshake (or QUIC over UDP if the browser negotiated HTTP/3), then TLS, then HTTP GET, then HTML, then more GETs for assets, usually hitting a CDN before origin. TCP is a reliable ordered byte stream. UDP is datagrams with no handshake. Horizon’s GStreamer camera at 60 FPS is the honest UDP-family example on this resume, not a claim that amazon.com video is my stack. Do not recite seven OSI layers unless they ask; map DNS and HTTP to application, TLS beside presentation, TCP or UDP to transport, IP to network, Ethernet and MAC to data link. The same walk at Ylogx is CloudFront, then ALB, then ECS. The resume number is sub-210 ms from cache and edge, not an LLM on the dashboard hot path. This GFG CN prompt is not a Job 10454435 live question.

Example: Browser resolves, connects 443, completes TLS with a cert that matches the name, GET /, CloudFront cache hit for static, origin for HTML. Ylogx is the same sequence at internship scale.

If they probe: cookies on later requests; 301 www versus apex; TLS name mismatch; 502 (bad gateway between CloudFront or ALB and origin) versus 504 (origin timeout).

Kafka was asked because that candidate’s stack had Kafka; this resume does not. Order is per partition, not topic-global. The same key hashes to the same partition, so that key is FIFO. More partitions buy consumer parallelism in a group, not a total order. Producer acks=all plus ISR is the durability versus latency knob. A consumer group is competing consumers on partitions. Replicated partitions and leader failover are the fault-tolerance story; a rebalance can pause a partition if offsets are mishandled. The Java mental model is ProducerRecord(topic, key, value); I did not run this in internships. Honest line: Postgres and Redis at Ylogx; if ordered events were required I would key by tenantId or dashboardId.

Example: If they insist on a sketch, new ProducerRecord<>("events", tenantId, json) so one tenant stays on one partition. I will not claim I operated Kafka at Ylogx.

If they probe: log compaction; exactly-once as idempotent producer plus transactions — name it, do not lecture; B+ Tree was the other igreaper CS item and belongs in the database chapter.

REST here means resources in URLs, HTTP verbs, a stateless server, and usually JSON. Cache with GET and headers, and treat errors as status codes, not 200 {success:false}. Ylogx BI was REST on FastAPI and NestJS; GraphQL and ProtoBuf are skills, not that app’s on-wire protocol. GraphQL helps nested over-fetch, while ProtoBuf fits high-frequency binary such as Argus-style metadata, not Recharts KPI JSON. Java mapping is @GetMapping or HttpClient.send, returning ResponseEntity.status(HttpStatus.NOT_FOUND) when the resource is missing. Authorization on this resume is REST plus RLS and RBAC across 3 org tiers, so a 200 with empty rows is the wrong face for a forbidden tenant. This IE.in list is not UTA two-DSA and not a 10454435 prediction.

Example: GET /kpis/ops with a JWT, NestJS guard, Postgres RLS, 200 JSON for the caller’s tier or 403 if the org is wrong. Report create is POST, not a GraphQL mutation on this app.

If they probe: PUT and DELETE are idempotent, POST is not; pagination; CORS is a browser rule, not REST itself; 401 versus 403.

The resume line is configured GoDaddy DNS with Route 53 to route traffic through an ALB. GoDaddy is the registrar. Route 53 is the authoritative hosted zone. Nameservers on GoDaddy must point at Route 53; split-brain records on both is a failure mode. Typical records are apex and www Alias A to CloudFront or ALB, with ALB health checks on ECS targets. Failure modes I will name are NS not delegated, TTL still on an old IP, and host-header mismatch on the ALB. DNS sits on the critical path of 99.9% uptime and sub-210 ms. The www versus non-www 403/noindex SEO debug is prep-only and not on the Aug 2026 resume, so I will not lead with it.

Example: Buyer visits the apex. Route 53 Alias answers CloudFront. CloudFront origin is the ALB. ALB forwards to a healthy ECS task. A leftover A record to an old IP with a long TTL looks like downtime with a healthy cluster.

If they probe: Alias versus CNAME on apex; health-check 502 when all targets drain; IPv6; do not tell the SEO isolation story unless they already heard it.

CloudFront is the CDN: cache JS, CSS, and images at the edge; origin is ALB then ECS. Fewer hits to containers is Frugality before a larger instance class. After deploy, Cache-Control and invalidation matter. Dashboard JSON is user-specific and RLS-scoped, so I will not cache tenant JSON at the edge. CloudFront is the AWS edge I can defend. Nginx is on the skills list as reverse proxy, TLS, and static, not “Ylogx edge was Nginx.” sub-210 ms is the latency number. Redis −35% bot DB latency is application cache, not the CDN; do not mix them.

Example: First paint of Recharts JS from a nearby PoP. GET /kpis/ops bypasses or uses a short TTL and still hits NestJS so RLS runs. Redis may hold a hot schema answer after a successful RLS query.

If they probe: CloudFront 403 (WAF, geo, signed URL) versus ALB 502 versus origin 5xx; invalidation versus versioned asset names.

Nginx is a reverse proxy, TLS terminator, static-file server, simple load balancer, and gzip hop. On projects the usual picture is proxy_pass to Node or FastAPI. ALB is managed L7 with host and path rules, target groups, and ACM certs. CloudFront is global cache and TLS at PoPs. A Java JAR would still sit behind Nginx or ALB; business logic does not live in the proxy. Honest line: I know Nginx as a proxy; the path I shipped at Ylogx is CloudFront → ALB → ECS. I will not invent a production Nginx TLS hop in AWS.

Example: Locally, location /api/ { proxy_pass http://nest; } and location /rag/ { proxy_pass http://fast; }. In AWS those path rules are ALB listener rules to ECS services.

If they probe: worker_connections; WebSocket Upgrade headers — only if they push, and I will not invent a WS Nginx config I did not ship.

HTTP is the client asks, the server answers, and the connection may close. Polling is repeating GET: simple, cacheable, and it works through proxies. A WebSocket starts as HTTP Upgrade, 101 Switching Protocols, then bidirectional frames on one TCP (or QUIC). I will describe that trade-off and I will not claim a socket fan-out bus that is not on the resume. WebSockets win for Argus-style camera alerts or tiles that would DDoS Postgres if polled every second. HTTP wins for the report builder, SQL RAG, and anything request-scoped behind RLS. Java 11 HttpClient.newWebSocketBuilder is a thirty-second sketch; Live Code is still DSA. Metrics I may use are 30 dashboards, ops +60%, and sub-210 ms API. Two-hundred-ten milliseconds is request latency, not a WebSocket tick rate.

Example: An ops KPI tile polls GET /kpis/ops every few seconds through CloudFront and ALB. An Argus alert could be a push. I will not say Ylogx shipped Redis pub/sub fan-out for all 30 tiles.

If they probe: sticky sessions versus Redis pub/sub across ECS tasks; idle timeouts and heartbeats; wss:// plus JWT on handshake; a socket is not a backdoor around RLS.

Live video treats a late frame as the wrong frame. UDP sends datagrams; the pipeline would rather drop than stall. TCP retransmission causes head-of-line blocking that freezes a 60 FPS GStreamer path. RTP sits on UDP; GStreamer is how Horizon moved camera frames. Loss becomes artifact, not freeze, if the pipeline is built for it. Java analogue is DatagramSocket and DatagramPacket — no accept, no connection — but Horizon code was ROS2, Python, and C++, not Java. Ylogx REST wants TCP and TLS so a report row is not dropped. Resume metrics are 60 FPS and ERC 17th / 80+. I will not quote FPS as an iperf SLA. GitHub Gstreamer-UDP supports the protocol story; it is not a separate product with extra metrics.

Example: Camera → GStreamer UDP/RTP across the rover network at 60 FPS. A dropped datagram is a glitch. The same resume’s Ylogx dashboard uses HTTPS so a KPI row is acked.

If they probe: why DNS still uses UDP 53 (and TCP when truncated); QUIC and HTTP/3 also use UDP but that is not Horizon; congestion control is on the application or RTP side.

OSI is seven layers: Application, Presentation, Session, Transport, Network, Data Link, Physical — a teaching model. TCP/IP is four: Application (HTTP, DNS, TLS in practice), Transport (TCP or UDP), Internet (IP), Link (Ethernet or Wi-Fi). Interview mapping is REST and WebSockets at application, the TCP handshake at transport, IP at network, MAC and Ethernet at link. TLS sits on TCP, or inside QUIC. I will not spend time on session versus presentation unless they insist. Ylogx HTTPS is application plus TLS plus TCP plus IP. Horizon camera is application plus UDP plus IP.

Example: Browser GET to CloudFront uses all four TCP/IP layers. Horizon 60 FPS GStreamer skips TCP on the camera path.

If they probe: where TLS lives (not “layer 6” as a job); QUIC combining TLS and transport over UDP; do not invent seven-layer Ylogx diagrams.

TCP is connection-oriented: three-way handshake, ordered byte stream, ACK and retransmit, congestion control. A socket is the four-tuple. UDP has no handshake, preserves message boundaries, and does not guarantee delivery or order; the header is small. UDP fits latency-sensitive media, DNS queries on port 53 (TCP if truncated), and QUIC/HTTP/3. Java is Socket and ServerSocket versus DatagramSocket. BufferedInputStream on TCP hides message boundaries; HTTP frames for you. TCP loss stalls all streams on that connection, which is HTTP/2’s head-of-line pain. UDP and QUIC can avoid that stall. Resume: REST and TLS are TCP; GStreamer live cam is UDP.

Example: new Socket(host, 443) for a Ylogx health check. DatagramPacket toward a GStreamer sink for a camera frame. I will not claim HTTP/3 on NestJS.

If they probe: head-of-line on HTTP/2 versus HTTP/3; checksums; UDP still has ports; “reliable UDP” is an application protocol on top, not magic.

The client sends SYN with its initial sequence number, the server replies SYN-ACK with its ISN, and the client ACKs so both sides have sequence space and data can flow. Close is FIN and ACK each direction (four-way), and TIME_WAIT holds the four-tuple so stray packets die. RST aborts; half-open means one side is gone and keepalive or a read error surfaces it. TLS is after TCP, except QUIC, so saying “HTTPS handshake” without TCP is incomplete. Java new Socket(host, port) blocks until the OS has finished the handshake, and ServerSocket.accept completes the server side. SYN flood is half-open SYNs filling the backlog, which is not a Ylogx war story.

Example: Browser to CloudFront 443: SYN, SYN-ACK, ACK, then ClientHello. new Socket("example.com", 443) in Live Code is that client side.

If they probe: simultaneous open; TIME_WAIT size; SYN cookies; why HTTP/3 and QUIC avoid this TCP dance; not a Job 10454435 named question.

HTTP 1.1 is text with persistent connections and a Host header; pipelining is rare, so you get one outstanding request per connection in practice, many connections, and head-of-line at the HTTP layer. HTTP 2 is binary frames, multiplexed streams on one TCP, and HPACK headers; server push is mostly unused, and packet loss still stalls that TCP connection. HTTP 3 is HTTP over QUIC/UDP with TLS 1.3 built in, 0-RTT resumption, no TCP head-of-line, and connection IDs that can survive NAT or IP change. Browser to CloudFront may negotiate 2 or 3, while origin to ECS is often HTTP 1.1 or 2. I will not claim we ran HTTP 3 on NestJS. Java 11 HttpClient speaks 1.1 and 2 via Version.HTTP_2, and stock JDK has no HTTP 3 one-liner. sub-210 ms is caching, edge, and pooling, not “because HTTP 3.”

Example: Chrome to CloudFront might be h2 or h3. ALB to NestJS on ECS is not a claim of HTTP/3. HttpClient.newBuilder().version(HttpClient.Version.HTTP_2) is the Java sketch.

If they probe: head-of-line difference between 2 and 3; HPACK versus QPACK; 0-RTT replay risk; do not credit latency to HTTP/3.

TLS gives confidentiality, integrity, and server authentication via a certificate. After TCP the flight is ClientHello, ServerHello plus cert, key agreement, Finished. TLS 1.3 is one RTT, and 0-RTT on resume. The cert must match the hostname using SNI. CloudFront and ALB terminate TLS; origin can be HTTP inside the VPC or TLS to the ALB. Java is https:// on HttpClient, or SSLSocket; the trust store is cacerts unless you custom a TrustManager, which you should not do in an interview. TLS is not JWT. TLS is the pipe; JWT is who the user is. Ylogx is HTTPS plus JWT and RBAC plus RLS. TLS is not tenant isolation.

Example: Browser to CloudFront on 443 with a cert for the Ylogx name. ALB can present an ACM cert. NestJS still checks JWT and Postgres still applies 3-tier RLS.

If they probe: MITM on cleartext HTTP; HSTS; “is TLS enough for tenant isolation?” — no, RLS; client certs not claimed.

Two-xx: 200 OK, 201 Created, 204 No Content. Three-xx: 301 or 302 for www versus apex, 304 Not Modified for CDN or browser cache. Four-xx: 400 bad input, 401 unauthenticated, 403 authenticated but forbidden under RLS or RBAC, 404, 409 conflict, 422 semantic, 429 rate limit. Five-xx: 500 bug, 502 bad gateway between ALB or CloudFront and origin, 503 overloaded, 504 origin timeout. Java is HttpStatus.FORBIDDEN versus UNAUTHORIZED. Returning 200 for a 403 to “hide” tenants is a leak and a lie. 403 is the HTTP face of a wrong org tier; 3-tier RLS is the real control. CloudFront 403 is not RLS 403; isolate the hop.

Example: Missing JWT → 401. Valid JWT, wrong org → 403 from the API; empty 200 is wrong. CloudFront 403 from a WAF rule is a different hop than Postgres RLS.

If they probe: 201 plus Location; 429 plus Retry-After (rate limiter live count is 1 in other loops, not UTA); 502 versus 504.

HTTP is request and response, client-driven; intermediaries understand methods, status, and cache. A WebSocket starts as HTTP with Upgrade: websocket and Connection: Upgrade, then framed messages both ways with no per-message status codes. Proxies must forward Upgrade. ALB supports WebSockets; naive idle timeouts kill sockets, so you heartbeat. Security is wss:// and still auth — ticket, cookie, or JWT on handshake. The same RLS rules apply: a socket is not a backdoor around Postgres. Use HTTP for CRUD and reports. Use WebSockets for event streams. Mix as REST to subscribe and WS to listen. Skills list has WebSockets; I will not invent a fan-out bus for the 30 KPIs.

Example: GET /reports/42 stays HTTP. A camera alert channel would Upgrade to wss:// and send frames. Ylogx 30 dashboards I describe as live-ish REST, not a claimed socket.io mesh.

If they probe: 101; ping/pong; sticky load balancer versus Redis pub/sub; SSE as server-to-client still-HTTP.

ARP maps IPv4 to MAC on the local net. It does not cross routers, which is why MAC changes per hop. A port is transport demultiplexing: 443 HTTPS, 80 HTTP, 53 DNS. WebSocket often shares 443 via Upgrade. NAT maps many private IPs to one public IP and breaks unsolicited inbound without port-forward or an ALB. ECS tasks are private. The ALB is the public VIP. Users never speak ECS task IPs. The path is Route 53 to CloudFront or ALB.

Example: Task 10.x talks to Postgres in the VPC using private IPs and local ARP. A laptop on the internet hits CloudFront, not 10.x.

If they probe: IPv6 and NDP instead of ARP; ephemeral ports; NAT timeout killing idle WebSockets; security groups versus NACLs at high level only.

InetAddress a = InetAddress.getByName("example.com");
System.out.println(a.getHostAddress());

try (Socket s = new Socket("example.com", 443)) {
  s.getOutputStream().write("ping".getBytes(StandardCharsets.US_ASCII));
}

byte[] buf = "frame".getBytes(StandardCharsets.UTF_8);
try (DatagramSocket ds = new DatagramSocket()) {
  ds.send(new DatagramPacket(buf, buf.length, InetAddress.getByName("10.0.0.2"), 5000));
}

HttpRequest req = HttpRequest.newBuilder(URI.create("https://example.com/health")).GET().build();
HttpResponse<String> res = HttpClient.newHttpClient().send(req, HttpResponse.BodyHandlers.ofString());
if (res.statusCode() == 403) { /* forbidden, not “empty 200” */ }

HttpClient.newHttpClient().newWebSocketBuilder()
    .buildAsync(URI.create("wss://example.com/ws"), listener);

return ResponseEntity.status(HttpStatus.NOT_FOUND).build(); // 404

REST is resource URLs, HTTP verbs, stateless JSON, cache with Cache-Control and CDN, and idempotent GET, PUT, and DELETE. Tie to resume in one breath: Ylogx REST on Docker and ECS, not “I ran EC2 by hand,” CloudFront in front, ALB after Route 53. S3 is objects such as models and PDFs. Postgres is RLS rows. NoSQL is when you do not join; session and hot answers went to Redis. I did not shard Ylogx. One primary plus RLS plus Redis is what I shipped. This list is IE.in L4 2025 fresher after BR, not UTA two-DSA, and not a 10454435 prediction.

Example: A report PDF might land in object storage. The metric row stays in Postgres under RLS. Redis holds a hot bot answer after a successful RLS read.

If they probe: 200, 201, 204, 400, 401, 403, 404, 429, 500; 401 versus 403; why REST not GraphQL for this BI app.

Independent SDE I live count for this design is 1. It was an OA-plus-three SD loop, not UTA two-DSA, not a second Rate Limiter, and not Job 10454435. Token bucket or sliding window; the key is user or IP; Redis if more than one box. Ylogx 99.9% and sub-210 ms are uptime and latency, not a claim I shipped this LLD. LC 8362604 “rate limiting decisions” were that candidate’s LP follow-ups. The HTTP face is 429 plus Retry-After. Full LLD lives in the OOD chapter and Answer-BIBLE, not FastAPI trivia here. Login Tracker as SDE I R2 is unverified; I will not lead with it.

Example: One Redis INCR on rl:{userId} per window; over limit returns 429. I will not say a FastAPI limiter was Ylogx production.

If they probe: token bucket versus sliding window; distributed clock skew; where the full LLD card is (OOP chapter / Answer-BIBLE).

Entities are user, channel, event, and delivery. Push versus poll is the first fork. Delivery is usually at-least-once plus an idempotent client, not exactly-once theater. Resume hooks are Argus alerts and Ylogx “real-time KPI dashboards.” I will not invent a socket bus that is not in a README. Skills list has WebSockets: live KPI tiles or camera alerts as a trade-off, not production fan-out I will defend as shipped. Argus numbers I may use are 24 FPS and 20+ cameras; that is the alert shape, not a claimed broker. This is Nitesh LinkedIn R2, WebSocket-adjacent, not 10454435.

Example: Argus alert: event row in Postgres, notify operators. Ylogx KPI: poll REST. If they ask WebSockets, describe Upgrade and pub/sub as a design, labeled as design not internship fact.

If they probe: at-least-once duplicates; email or SMS versus in-app; sticky sockets across ECS.

The same split as Ylogx: HTTP and RBAC at NestJS, SQL RAG at FastAPI, rows at Postgres. The controller is not the database. Bhavya was HM, not R2. Login Tracker new_login / get_oldest_login as SDE I R2 is unverified (mentor only); I will not lead with it. Java Live Code can still draw Controller → Service → Repository. NestJS guards sit where Spring security filters sit; FastAPI Depends is similar. RLS remains in Postgres so an app miss is not a leak across 3 org tiers.

Example: ReportController.getKpi checks u.canRead(orgId) then svc.kpi; the SELECT still runs as the user role.

If they probe: why both RBAC and RLS; Facade versus Service; do not open Login Tracker.

The resume names a custom report builder using Python, FastAPI, NestJS, RESTful APIs, and PostgreSQL. NestJS is the TypeScript API: authz, RBAC, report CRUD, dashboard contracts. FastAPI is Python: LangChain SQL RAG, report generation, Pandas-shaped work. One language would work; two runtimes matched typed HTTP product versus Python AI and SQL. Postgres is the source of truth either way. FastAPI gives Pydantic, async, and OpenAPI for free. NestJS gives modules, guards, and DI, the same shape as Spring layers. Do not say NestJS is faster than FastAPI. Throughput was Redis −35% bot DB latency plus CloudFront, not framework micro-benchmarks. Java bridge: NestJS module is like Spring @Service; FastAPI route is like @RestController. I did not ship this as Spring. IQVIA also used FastAPI, with 200+ sites and 200+ page BRDs — different job, same framework family.

Example: React calls NestJS GET /dashboards. Report generation POSTs into FastAPI. Chatbot NL → SQL runs on FastAPI as the user’s DB role.

If they probe: why not one runtime; gRPC between them (not claimed); “which is faster” → Redis and CDN, not a bake-off.

The browser, React and Recharts, hits CloudFront, then ALB, then ECS Docker running NestJS and/or FastAPI, then Redis, then Postgres RLS. DNS is GoDaddy nameservers to Route 53 to ALB, often via CloudFront. Report builder is NestJS CRUD plus FastAPI generation. Chatbot is NL to constrained SQL as the user’s DB role so RLS applies. Thirty KPI dashboards are REST reads, not LLM on the hot path. Metrics I may use are 40% faster reports, 99.9% uptime, SQL RAG +65% analysis productivity, Redis −35% bot DB latency, 30 dashboards +60% ops, and sub-210 ms. Sub-210 ms is cache, pooling, and CDN.

Example: Dashboard tile: cached JS from CloudFront, JSON from NestJS with RLS, no LLM. Chatbot: FastAPI generates SQL, Redis may serve a hot answer, Postgres still enforces tier.

If they probe: which service owns JWT; can CloudFront cache /kpis (not tenant JSON); 502 versus 504 on this path.

The Ylogx BI bullet is RESTful APIs. GraphQL and ProtoBuf are Technical Skills, not the Ylogx protocol. REST is cacheable resources, HTTP semantics, and CloudFront-friendly. Thirty Recharts KPIs are known URLs, not a client-shaped graph. GraphQL lets the client pick fields and helps nested product graphs such as SaaS or VR; over-fetch was not the Ylogx pain on first cut. ProtoBuf is binary, schema’d, and gRPC-friendly. A skills-level use is high-frequency internal payloads such as Argus frame metadata, not JPEG, and not browser KPI JSON. One paragraph: REST for public HTTP; GraphQL if the client needs a nested resource graph; ProtoBuf when the payload is chatty and both ends own the .proto.

Example: GET /kpis/ops JSON to Recharts. A GiftedBooks-shaped nested catalog could be GraphQL (sub-300 ms, 99.5% is the other HTTP SLA if they leave Ylogx). Argus bbox metadata could be ProtoBuf on an internal path; 24 FPS and 20+ cameras are resume numbers, not a claim I shipped gRPC there.

If they probe: why not GraphQL everywhere; browser and grpc-web; field-id compatibility on .proto.

A BI query is aggregation over Postgres: joins, GROUP BY, grain. The bot already returns SQL, not a nested User → Orders → Items tree. GraphQL does not replace RLS. Resolvers that hit the DB with a service-role user leak the same way as app-only WHERE org_id. Naive resolvers are N+1; a KPI tile is one SQL. GET /kpis/ops can sit behind CloudFront; POST { query } is not cacheable without persisted queries, which is extra machinery for 30 fixed dashboards. NestJS guards on routes are obvious; field-level authZ is easy to miss. Control was 3-tier RBAC plus RLS. I would use GraphQL if many widgets over-fetched REST blobs, or a mobile or VR client needed sparse nested reads. That was not the Ylogx first cut. 30 dashboards, sub-210 ms, and 40% faster reports were measured REST plus cache, not a GraphQL rewrite.

Example: One GET /kpis/ops → one SQL. GraphQL { kpis { a b c } } might be one resolver or three. SQL RAG is generated SQL as user role, not GraphQL.

If they probe: DataLoader; persisted queries; introspection as an attack surface — keep it high level, no exploit steps.

The resume says 30 real-time KPI dashboards; skills say WebSockets. I will not invent a socket fan-out bus. Polling REST every N seconds is simple, CDN and ALB friendly, and good enough for ops KPIs that tolerate seconds of lag. WebSocket is server push, needs sticky sessions or Redis pub/sub, and is harder to cache. Honest wording is live-ish via API. If they probe sockets: WebSockets for Argus-style alerts or tick-level tiles; poll for 30 Recharts. sub-210 ms is HTTP response time, not WebSocket RTT; do not mix the numbers. Ops +60% is the outcome, not a tick-rate SLA.

Example: Five-second poll of /kpis through ALB. Design-only: check JWT on open, subscribe org:{id}, Redis pub/sub so any ECS task can fan out — labeled as design, not shipped Ylogx.

If they probe: heartbeat; ALB idle timeout; wss; RLS on subscribe.

Tools on the resume include OpenAPI Spec and Postman. FastAPI generates OpenAPI from Pydantic. NestJS does the same via @nestjs/swagger. The contract is request and response schemas and status codes so React and the Python bot do not drift. Postman collections come from the spec. It is not a separate OpenAPI microservice. It is how the REST surface is documented and tested. Java analogue is SpringDoc or OpenAPI 3 annotations. Live Code will not need the YAML.

Example: @app.get("/kpis/{kpi_id}", response_model=KpiOut) is the spec. NestJS ApiOkResponse is the same idea on the TypeScript side.

If they probe: drift when a hand-edited YAML diverges; codegen clients; securitySchemes as bearer JWT — still not RLS.

The databases list is PostgreSQL and Prisma ORM. The Ylogx bullet names PostgreSQL, not Prisma. Prisma is a TypeScript schema that yields migrations plus a type-safe client, which fits NestJS CRUD. FastAPI SQL RAG still needs raw parameterized SQL and the RLS role. An ORM that hides the query the model generated is the wrong tool for that path. Claim: skills include Prisma; warehouse was Postgres; RAG executes SQL as the user role. findMany({ where: { orgId } }) is still app-level; miss one query and you leak. RLS in Postgres is the backstop.

Example: NestJS Report model with orgId. RAG: SET ROLE user_tier; then SELECT metric, ts FROM ops_kpi WHERE day >= $1 LIMIT 1000.

If they probe: Prisma versus Hibernate — same idea, Live Code needs neither; does Prisma generate RLS? No.

Skills: Nginx. Ylogx deploy: CloudFront, ECS, Docker, ALB, Route 53. The resume does not say Nginx sat in front of production. A reverse proxy terminates TLS, path-routes /api versus /rag versus static, gzips, hides origins, and can load-balance. ALB does L7 routing to ECS tasks. CloudFront is the edge. Nginx is the same pattern on a box for local, dev, or a VM. If they say “draw Nginx,” answer: same role as ALB and CloudFront; I shipped AWS managed; I know the box version. Do not stack Nginx and ALB and CloudFront on one invented diagram unless you can say which hop did TLS.

Example: upstream nest { server 127.0.0.1:3000; } and location /api/ { proxy_pass http://nest; } is the box version of an ALB target group and path rule.

If they probe: which hop has the ACM cert; gzip at CloudFront versus origin; WebSocket Upgrade on Nginx — do not invent prod config.

Skills: GitHub Actions, CI/CD Pipelines, Docker, Kubernetes. Ylogx: automated CI/CD pipelines, Docker on ECS, 99.9% uptime, sub-210 ms. The path I can defend is build image, push registry, rolling deploy ECS service, Actions YAML on GitHub. It is not a twenty-stage textbook. It is not “I owned EKS.” Kubernetes is on the skills list; the production path I defend is ECS plus Docker plus CloudFront. Tests: NestJS API tests; SQL fixtures that RLS denies cross-tier rows; RAG golden NL to expected SQL shape. Do not steal IQVIA LangSmith for Ylogx.

Example: on: push → test → docker build → push → ecs update-service. Secrets in GitHub, never in YAML.

If they probe: kubectl apply is skills-list, not the Ylogx story; fail closed if tests fail; 99.9% is boring pipelines.

40% faster report generation: measure first (Are Right, A Lot). That is the FastAPI generation path, not the LLM on every dashboard GET. sub-210 ms is Redis hot schema and answers (−35% bot DB latency), connection pooling, and CloudFront for static and API edge, with the LLM off the KPI hot path. 99.9% is Docker and ECS plus CI/CD so deploys are boring, plus ALB health checks. BI that is down is not “AI.” Frugality is Redis and CDN before a larger RDS class. Do not invent QPS or headcount. GiftedBooks sub-300 ms and 99.5% is a second HTTP example if they leave Ylogx.

Example: Dashboard GET never calls the LLM. Report job on FastAPI got faster after measuring the generation path. Redis cut bot DB latency 35%. Edge cache covers static.

If they probe: how measured — I will not invent a Grafana screenshot; mixing Redis −35% with CloudFront sub-210 ms as one number is the trap.

REST constraints I will say: stateless, uniform interface, resource in the URL, representation in the body, usually JSON. GET retrieves and is safe, idempotent, and cacheable; POST creates or runs a non-idempotent action; PUT replaces and is idempotent; PATCH is partial; DELETE is idempotent. Create returns 201 plus Location, and 204 has no body. Client errors are 400 bad input, 401 unauthenticated, 403 authenticated but forbidden under RBAC or RLS, 409 conflict, and 429 rate limit. 502 and 503 mean proxy or origin down. Ylogx used these codes on FastAPI and NestJS.

Example: PUT /reports/{id} retried after timeout does not duplicate. POST /reports retried might. Java: ResponseEntity.status(HttpStatus.NOT_FOUND).build().

If they probe: safety versus idempotency; PATCH versus PUT; why GET must not mutate.

GraphQL is one endpoint, a client query, a typed schema, and introspection. Over-fetch goes down, under-fetch goes down, and N+1 goes up unless you add DataLoader. REST is many URLs, HTTP cache, CDN, and simpler authZ per route. Neither is a database. Neither is RLS. Ylogx first cut was REST because 30 dashboards are fixed URLs. GraphQL remains a skill for nested client graphs. I will stop after that contrast unless they want the BI decision, which is the resume question above.

Example: REST GET /kpis/ops. GraphQL { kpis { a b c } } at /graphql. Same Postgres underneath; RLS still required.

If they probe: subscriptions versus WebSockets; persisted queries; I did not run GraphQL as Ylogx on-wire.

A .proto schema generates code. The encoding is binary with field numbers, backward compatible if you do not reuse field ids. gRPC is HTTP/2 plus ProtoBuf plus RPC, strong for service-to-service. The browser story is messier: grpc-web or a JSON gateway. JSON REST is human-debuggable, works in Postman, and sits well behind CloudFront. ProtoBuf fits cameras, telemetry, and internal chatty payloads. Argus 20+ cameras and 24 FPS is a place metadata could be binary; JPEG frames are not ProtoBuf. Ylogx dashboards stayed JSON REST.

Example: message Meta { int32 camera_id = 1; } for internal logs. Browser still GET /kpis JSON. Do not claim Ylogx spoke gRPC.

If they probe: HTTP/2 multiplexing; protobuf3 optional; field 1 forever; why not ProtoBuf for Recharts.

The handshake is HTTP Upgrade, then 101 Switching Protocols, then full-duplex frames, not request and response. Across ECS you need a sticky load balancer or Redis pub/sub. Idle timeouts need heartbeats. Auth belongs on connect with a token, not only the first HTTP hop. SSE is server-to-client only and still HTTP. Polling is repeated GET. Pick from lag versus ops cost. Skills: WebSockets. Production honesty: do not claim the 30 KPI fan-out.

Example: Request headers Upgrade: websocket, Connection: Upgrade. Response 101. Then frames. Java: newWebSocketBuilder().buildAsync(URI.create("wss://example.com/ws"), listener).

If they probe: Sec-WebSocket-Key at a name-only level; ping; ALB idle; SSE versus WS.

A reverse proxy is what the client talks to; it talks to origin. Jobs are TLS, routing, and buffering. A load balancer fans out to many origins — ALB to ECS tasks. A CDN such as CloudFront caches at the edge and fetches origin on miss. Nginx proxy_pass is the box version of an ALB target group. upstream is the task list. Ylogx is CloudFront (CDN) → ALB (load balancer) → ECS. Nginx is skills, not the claimed production hop.

Example: User → CloudFront PoP → ALB → task port 3000 or 8000. Locally the same picture is one Nginx with two upstreams.

If they probe: L4 versus L7; which hop terminates TLS; why not Nginx plus ALB plus CloudFront stacked without a reason.

OpenAPI 3 is machine-readable paths, schemas, and securitySchemes such as JWT bearer. You generate clients, mock servers, and contract tests. Drift is the bug: the spec must match runtime. FastAPI wins because the spec is the types. Comments in code rot. Postman from the spec is how Ylogx-shaped APIs stay testable. Live Code will not need hand-written YAML.

Example: Pydantic KpiOut is the 200 schema. A comment // returns kpi is not a contract.

If they probe: OpenAPI 2 versus 3; SpringDoc; I will not write YAML in Live Code.

An ORM maps objects to rows and owns migrations. It hides N+1 and generated SQL. That is bad for SQL RAG because you want the SQL. Raw parameterized SQL is required for RLS-as-role, timeouts, row caps, and denying catalog probes. Migrations still belong in CI, whether Prisma migrate or .sql. Schema change is not a production hotfix by hand. Prisma is skills; the Ylogx warehouse is PostgreSQL.

Example: NestJS CRUD via Prisma or a similar client is fine. RAG: parameterized SELECT with LIMIT and role. Never concatenate natural language into SQL.

If they probe: N+1 findMany then loop; query builder as a middle ground; RLS is not generated by Prisma.

A workflow on push or pull_request has jobs and steps on a runner. Secrets live in GitHub, not in the YAML. A typical image pipeline is checkout, test, docker build, push, deploy by updating an ECS task definition. Fail closed: do not deploy if tests or image build fail. 99.9% is boring pipelines, not heroics. Kubernetes apply is skills-list; the Ylogx story is ECS plus Docker.

Example: A pull request runs tests only. Merge to main builds and ecs update-service. AWS role via OIDC, not a committed key.

If they probe: matrix builds; self-hosted runners — I will not invent a farm; never commit keys.

// Controller → Service → Repository. Same split as NestJS guards + FastAPI RAG.
class ReportController {
  ReportService svc;
  String getKpi(String orgId, String kpiId, User u) { // RBAC here
    if (!u.canRead(orgId)) throw new Forbidden();
    return svc.kpi(orgId, kpiId); // DB still has RLS
  }
}

// PUT /reports/{id} body=...  → same id, same result if retried
// POST /reports               → new id each time; retry may duplicate

// Poll: GET /kpis every 5s — ALB/CloudFront OK
// WS: @OnOpen check JWT; subscribe org:{id}; Redis pub/sub so any ECS task can fan-out
// Do not claim Ylogx shipped the WS column.

# Same job as ALB path rules. Skills list. Prod hop I shipped: CloudFront → ALB → ECS.
upstream nest { server 127.0.0.1:3000; }
upstream fast { server 127.0.0.1:8000; }
location /api/ { proxy_pass http://nest; }
location /rag/ { proxy_pass http://fast; }

# FastAPI: decorator + Pydantic = OpenAPI. Not a second service.
@app.get("/kpis/{kpi_id}", response_model=KpiOut)
def kpi(kpi_id: str, user=Depends(auth)): ...

// NestJS CRUD OK. Not the SQL RAG path.
model Report { id String @id; orgId String; }

-- RAG executes parameterized SQL SET ROLE user_tier; RLS applies.
SELECT metric, ts FROM ops_kpi WHERE day >= $1 LIMIT 1000;

# Skills: GitHub Actions. Ylogx: CI/CD to ECS/Docker.
# on: push
# jobs: test → docker build/push → ecs update-service
# secrets: registry + AWS role. Never commit keys.