Zero→Hero
0/17
Module 5 · Edges & Capstone · Unit 16

Security, Analytics & the Frontend Edge

Three cross-cutting topics from your list, bundled. Security and analytics matter in almost every design; the web-client topics get a fast, interview-sufficient pass (this is a backend track).

⏱ 30 min Prereq: Units 07, 10 You'll be able to: address security, analytics, and client tradeoffs briefly but credibly

By the end of this unit

Security checklist

AreaWhat to say
AuthNTokens/sessions (JWT or opaque), OAuth/OIDC for third-party login, MFA for sensitive accounts.
AuthZLeast privilege; RBAC/ABAC; check permissions on every request at the gateway/service.
EncryptionTLS in transit; encryption at rest for sensitive data; hash+salt passwords (bcrypt/argon2) — never store plaintext.
Input handlingValidate/sanitize; parameterized queries (SQL injection), output encoding (XSS), CSRF tokens.
SecretsA secrets manager (Vault/KMS), not env files in git; rotate keys.
Abuse / DDoSRate limiting, WAF, bot detection at the edge (Unit 10).
Where ML fits "security" Your source list pairs Security with "machine-learning" — that's abuse, fraud, and content safety detection: models flag spam, fake accounts, payment fraud, and unsafe media (run in the async pipeline, Unit 11). Frame ML as a signal feeding rate-limits/holds/human review, not a sole gatekeeper, and mention the feedback loop from labeled data.

Analytics — understanding user behavior

Analytics is a classic write-heavy stream feeding offline reads. The pipeline:

client events Kafka stream/batch data warehouse dashboards/ML
Events → durable log → stream (real-time) and/or batch (ETL) → columnar warehouse (BigQuery/Redshift/Snowflake) → dashboards, A/B tests, ML features.

Key points to mention: collect events client- and server-side; buffer through Kafka so spikes don't hurt the app; serve analytical queries from a columnar warehouse (OLAP), kept separate from your transactional DB (OLTP) so heavy analytics never slows user traffic. Lambda/Kappa architectures combine real-time + batch views.

The frontend edge — fast pass

Backend interviews touch these only lightly, but you should hold your own:

SSR vs CSR (Next.js)

Server-side rendering sends ready HTML → faster first paint & better SEO, more server cost. Client-side ships JS that renders in-browser → richer interactivity, slower first load. Frameworks like Next.js mix both (SSR/SSG/streaming) per route.

Native vs React Native

Native (Swift/Kotlin) → best performance & platform fidelity, two codebases. React Native / cross-platform → one codebase, faster shipping, occasional native escape hatches for performance-critical bits.

Framework selection

React/Angular/Vue choice is mostly ecosystem, team familiarity, and developer productivity — not raw capability. "Use what the team knows and what the hiring market supports" is a fine answer.

Async vs sync (asyncio)

Async shines for I/O-bound work (many concurrent network/DB waits) — high concurrency on few threads. Sync is simpler and fine for CPU-bound or low-concurrency work. Match the model to the workload.

Also worth a sentence: serve assets (images/JS/CSS) via CDN with fingerprinted filenames (Unit 10), lazy-load and pick correct image sizes (Unit 11) so clients fetch the right variant.

Keep it brief On a backend track, give one crisp tradeoff sentence per frontend topic and pivot back to data/scale. Knowing the tradeoff exists is enough; don't spend your deep-dive budget here.
Quick check
Why run analytics queries against a columnar data warehouse instead of your production transactional database?
Isolation + columnar speed. Big analytical scans would contend with user traffic on the OLTP store and run slowly on row storage. A separate columnar warehouse keeps user requests fast and answers aggregations efficiently — the OLTP/OLAP split.
Quick check
For a server handling thousands of concurrent, mostly-waiting database/network calls, which model fits best?
Async for I/O-bound. When most time is spent waiting on I/O, an event loop handles thousands of concurrent waits cheaply. A thread-per-request model wastes memory and context-switches. For CPU-bound work, though, async doesn't help — you need more cores/processes.

Practice before you move on

Add a security + analytics layer to the photo app: how a request is authenticated/authorized, two attacks you defend against and how, where ML flags abusive uploads, and a one-line analytics pipeline. Then give a single-sentence answer to "web or native client, and SSR or CSR?"

Finished this 30-min unit?