Tech 101 and System Design for PMs

Mark module complete Expand all

9.1 How the internet works (the 60-second version)

• IP address: numeric address of a machine. DNS: the internet's phone book (name → IP).
• TCP/IP: reliable delivery of data packets. HTTP: the request/response language of the web. HTTPS = HTTP over TLS, which encrypts data in transit and verifies the server's identity.

9.2 Frontend, backend and client–server architecture

9.3 APIs, REST, GraphQL and JSON

An API (Application Programming Interface) is a contract for how one piece of software asks another for data or an action.

REST organises an API around resources (nouns) with standard HTTP methods; GraphQL exposes a typed schema where the client asks for exactly the fields it needs in one query.

REST
GET  /restaurants/42/menu            → menu items
POST /orders            {cart...}    → 201 Created, {order_id}
GET  /orders/9001                    → order status

GraphQL (one request, client chooses fields)
query {
  order(id: "9001") { status eta restaurant { name } items { name qty } }
}

JSON (JavaScript Object Notation) is a common text format of key–value pairs and lists:

{
  "order_id": "9001",
  "status": "out_for_delivery",
  "eta_minutes": 12,
  "items": [ { "name": "Veg biryani", "qty": 1, "price_inr": 260 } ],
  "fees": { "delivery_inr": 45, "platform_inr": 5, "is_estimate": false }
}

9.3.1 HTTP methods and status codes

Actual behaviour depends on the API contract. Idempotent means doing it twice has the same effect as once — vital for payments (use idempotency keys so a retried “charge” doesn't charge twice).

9.4 Authentication, authorisation and OAuth

• Authentication (authN): who are you? (password, OTP, passkey, biometrics, SSO).
• Authorisation (authZ): what are you allowed to do? (roles, permissions, scopes).
• OAuth 2.0: a standard for delegated authorisation — letting an app access a user's resources at another service without sharing the password, via scoped access tokens. OpenID Connect (OIDC) adds an identity layer on top of OAuth 2.0 for “Sign in with…”.

9.5 Databases, SQL vs NoSQL, and data modelling

ACID (Atomicity, Consistency, Isolation, Durability) guarantees matter for money: a payment and its ledger entry must succeed or fail together.

Data modelling defines entities, attributes and relationships — often drawn as an ER diagram:

9.6 Cloud computing: AWS, Azure and GCP

Cloud computing rents computing resources on demand. Service models: IaaS (virtual machines, storage), PaaS (managed platforms/databases), SaaS (finished software), plus serverless (run code without managing servers; pay per use).

PM questions: What does it cost per user/transaction? Which region holds the data (residency rules)? What are the provider's SLAs? Are we locked into proprietary services? Product names and offerings change — check current documentation.

9.7 Monolith vs microservices

9.8 Caching, load balancing, queues, event-driven systems, webhooks and CDNs

• Caching: keep frequently used data in fast storage (memory) to cut latency and load. Trade-off: staleness — when must the cache refresh?
• Load balancer: spreads requests across servers; removes unhealthy ones; enables horizontal scaling.
• Message queue: producers put work on a queue; consumers process it later — smooths spikes and decouples services (e.g., send confirmation emails asynchronously).
• Event-driven architecture: services publish events (“OrderPlaced”) that others subscribe to; adds flexibility, complicates tracing.
• Webhook: an HTTP callback one system sends to another when an event happens (“payment succeeded”). Receivers must verify signatures, handle duplicates and out-of-order events, and reconcile with their own records.
• CDN (Content Delivery Network): servers near users cache static content (images, scripts, video) to reduce latency.

9.9 Scalability, reliability, availability, latency and throughput

• Scalability: ability to handle more load by adding resources — vertical (bigger machine) or horizontal (more machines).
• Reliability: the system does the right thing consistently (correct results, no data loss).
• Availability: share of time the system is usable.
• Latency: time to respond to one request; report percentiles (p50, p95, p99), not just averages.
• Throughput: requests (or transactions) processed per second.

Little's law example: 200 requests/second × 0.25 s average time in system = 50 requests in flight — useful for sizing connection pools and worker counts.

9.9.1 Rate limits

APIs limit how many requests a client can make (e.g., 100/minute) to protect capacity and enforce fairness or pricing tiers. Exceeding limits returns 429 often with a Retry-After header. PM implications: quotas per plan, back-off and retry design, batching, and partner contracts (third-party API limits can cap your feature).

9.10 Security fundamentals

• Principles: least privilege, defence in depth, secure defaults, encrypt in transit (TLS) and at rest, validate all input, log security events, rotate secrets.
• OWASP Top 10 (web risks such as broken access control, injection, cryptographic failures, security misconfiguration, vulnerable components) is the standard checklist.
• Common PM-visible issues: broken authorisation (user A can see user B's order by changing an ID), exposed API keys in frontends or repos, weak password resets, missing rate limits on OTP/login.
• Card data: handling card numbers brings PCI DSS obligations; most products use a payment provider's hosted fields/tokenisation to stay out of scope.

9.11 Privacy and compliance basics

• Data minimisation, purpose limitation, consent, retention limits, user rights (access, correction, deletion) are common principles.
• Regimes you may meet: GDPR (EU), India's Digital Personal Data Protection Act, 2023, CCPA/CPRA (California), sector rules (banking/KYC, health). Payment card data: PCI DSS.
• PM practice: privacy review for new data uses; no PII in analytics events; data-residency questions in vendor selection; get qualified legal advice for interpretation.

9.12 System architecture diagrams

When drawing a system in an interview or doc: clients → edge (CDN, gateway) → services → data stores → external providers, then annotate data flows, sync vs async calls, failure points and where PII lives. Label assumptions. Keep it to 6–12 boxes.

9.13 Technical debt and engineering estimation

Estimation: ask for ranges with assumptions (“5–8 days if the pricing API is stable”), break work down, identify unknowns (spikes), and track estimate accuracy over time — not to blame, but to plan. Common traps: anchoring on the PM's wish date; ignoring testing, review and deployment; forgetting non-functional work.

9.14 Agile delivery, CI/CD and feature flags

• CI (Continuous Integration): code changes are merged frequently and automatically built and tested.
• CD (Continuous Delivery/Deployment): every change that passes tests is releasable (delivery) or automatically released (deployment).
• Feature flags: turn features on/off (or for a percentage/segment) without redeploying — enabling staged rollouts, A/B tests and kill switches. Clean up stale flags (they are a form of tech debt).

9.15 Observability

Observability = being able to understand what a system is doing from its outputs: logs (events), metrics (numbers over time), traces (a request's path across services). Reliability targets:

• SLI (service level indicator): a measured value, e.g., % of checkout requests succeeding within 2 s.
• SLO (objective): the target, e.g., 99.9% over 30 days.
• SLA (agreement): a contractual promise with consequences, usually looser than the SLO.
• Error budget: 100% − SLO. At 99.9% per 30 days the budget is 43.2 minutes; if it's spent, prioritise reliability over features.

9.16 Technical trade-offs a PM should recognise

9.17 System design examples

The format for each: requirements → core components → data flow → key risks → PM decisions/metrics.

9.17.1 1 · Payment processing

Key risks: double charges on retry; webhook lost/duplicated/out of order; timeouts leaving status unknown (“pending”); fraud; refunds. PM decisions: show “payment pending” states honestly; retry UX (another method, saved cart); refund SLA; success-rate SLO by method; reconciliation ownership. Metrics: payment success rate (by method/bank), time-to-confirm, duplicate-charge reports, refund time, chargeback rate.

9.17.2 2 · Food delivery

Key risks: restaurant doesn't accept; ETA errors; courier shortages at peak; menu/price staleness. PM decisions: order state machine and customer messaging; batching policy; ETA confidence ranges; cancellation rules. Metrics: order acceptance time, on-time rate, ETA error (p50/p90), cancellations by cause, contribution per order.

9.17.3 3 · Ride-hailing

Components: rider app, driver app (location every few seconds), location service (geospatial index), matching/dispatch, pricing (base + surge), trip service, payments, safety (SOS, trip sharing), ratings. Key challenges: real-time location at scale, fair and fast matching, dynamic pricing with guardrails, fraud, safety. PM metrics: ETA to pickup, match rate, cancellation rate (rider and driver), surge frequency, driver utilisation and earnings, safety incidents.

9.17.4 4 · Notifications

Components: event producers → notification service (templates, user preferences, rate limits, quiet hours) → channel providers (push, SMS, email, WhatsApp) → delivery receipts. Key risks: spam/fatigue, duplicate sends, wrong user, timezone errors, provider outages, consent. PM decisions: priority tiers (transactional vs marketing), frequency caps, opt-outs, fallbacks (push → SMS for critical). Metrics: delivery rate, open/click, opt-out rate, complaints, time-to-deliver for transactional messages.

9.17.5 5 · Customer onboarding (fintech KYC)

Key risks: high drop-off at document upload; vendor latency/outages; false rejections (bias, poor image quality); fraud; data protection. PM decisions: progressive onboarding (collect only what is needed now), save-and-resume, camera guidance, manual-review SLAs, adverse-action explanations. Metrics: step completion, time to decision, auto-approval rate, manual review backlog, fraud rate, complaints.

9.18 Exercises with model answers

9.19 Interview perspective

9.20 Key takeaways

• Think in requests and responses; every network hop adds latency and failure modes.
• Know HTTP methods/codes, authN vs authZ, OAuth scopes and idempotency.
• Pick databases by access pattern and consistency needs; vector DBs complement, not replace, transactional stores.
• Reliability maths: dependencies multiply; report p95/p99 latency; manage error budgets.
• Caches, queues, webhooks and CDNs trade freshness, complexity and cost for speed and resilience.
• Security and privacy are product requirements: least privilege, no secrets in clients, no PII in analytics.
• In system-design interviews: requirements → components → data flow → failures → metrics.

9.21 Check your understanding

9.22 Recommended resources

• MDN Web Docs: HTTP — methods, status codes, caching.
• OWASP Top 10.
• OAuth 2.0 (oauth.net) and OpenID Connect.
• Google SRE Book: Service Level Objectives.
• GitHub Docs: Hello World (from your course notes).
• System Design Primer (GitHub).