Scaling
53 bites tagged Scaling — interview questions with model answers, and 60-second explainers.
PM2 cluster mode and multi-core utilization?
Cluster mode forks multiple worker processes using Node.js cluster module, distributes load, uses all CPU cores. understanding multi-process concurrency and PM2's cluster mode.
Cross-server Socket.IO communication in horizontal scaling?
Local io.emit() only reaches local sockets, need adapter (Redis) for inter-server broadcast. distributed system messaging and adapter patterns. assuming io.emit() broadcasts globally without an adapter; it doesn't.
Scaling one researcher across three squads
Triage by impact, enable democratized research with guardrails, build reusable templates and a shared repository. Scaling research without becoming a blocker.
Choosing Uvicorn worker count in production
Workers exist to use multiple CPU cores past the GIL; a common starting point ties count to cores, then you tune by load testing, balancing CPU and memory (each worker is a full copy) against connection-pool… Sizing process parallelism.
worker_threads versus cluster: when to use each
Worker_threads offloads CPU-bound compute within one process with shared-memory transfer; cluster forks processes to scale IO-bound request throughput across cores. Matching the concurrency tool to the workload.
Purpose of the Node.js cluster module
Cluster forks worker processes sharing one listening port, so requests spread across CPU cores via the OS, raising throughput and adding resilience. Knowing Node is single-threaded per process and how to use all cores.
Scaling across cores with cluster and os
Os.cpus gives core count, the primary forks one worker per core, all workers share the listening port, the OS load-balances connections. scaling single-threaded Node across cores. thinking one Node process uses all cores.
Federating reliability ownership to product teams
Build a self-service reliability platform (golden paths, paved roads), train teams and embed SLO/on-call practices, and govern with standards plus error budget… Whether you can scale reliability by enabling teams, not gatekeeping.
Diagnosing poor distributed training scaling
Communication overhead (gradient all-reduce, interconnect), data-loading starvation, load imbalance, and small per-GPU batches; profile with the PyTorch profiler and Nsight. distributed training bottlenecks.
Why chain-of-thought helps large models but not small ones
Small models lack reliable multi-step reasoning, so CoT just adds error-prone steps; adapt by using few-shot/fine-tuning or distillation for small tiers. Understanding emergent abilities and tier-aware prompting.
Tensor versus pipeline parallelism for large models
Tensor parallelism splits individual layers across GPUs needing fast interconnect; pipeline parallelism splits layers into stages across GPUs. multi-GPU model sharding strategy.
Centralized vs federated design system team models
Centralized gives consistency and quality but bottlenecks; federated scales contribution but risks fragmentation; many teams use a hybrid with central governance. Org model trade-offs.
A federated design system governance model
Let the product team own the component as maintainers, with the core team setting standards, reviewing against a checklist, and owning the platform and tokens. Scaling contribution via federation.
How would you speed up slow single-GPU training?
Vertical scaling to bigger or multi-GPU instances, then data-parallel or model-parallel distributed training across nodes. knowledge of scaling training.
Read replicas in managed relational databases
A read replica is an async copy of the primary that serves read-only queries, offloading the primary and scaling read-heavy workloads; expect replication lag. scaling reads and replication basics.
Maximizing object-store throughput for small files
Spread keys across prefixes for partition parallelism, batch small files, parallelize and use multipart uploads. object-store scaling internals.
Research Governance Model
A research governance model is the operating system for scaling insights, trading autonomy for coordination so studies do not collide. It matters when teams share users and budgets.
ResearchOps Playbooks: Standardize UX Research
A ResearchOps playbook is your team's operating manual for repeatable research. It matters when multiple researchers recruit, analyze, and report across squads. The footgun is writing it once and letting it rot instead of treating it as a living process.
ResearchOps Maturity Matrix: Built for Operations
UX maturity scores insights; ResearchOps maturity scores the factory producing them. Use it to audit governance, participant pipelines, and tooling strategy. The mistake is judging research quality instead of operational infrastructure.
Research Democratization: Scale Without Diluting Quality
Research democratization is controlled expansion, not chaos. Non-researchers run simple interviews while pros own complex design. It helps teams move fast when researchers are scarce, but the footgun is untrained staff picking methods or running quant studies.
ResearchOps: The Pit Crew for User Research
ResearchOps is the backstage crew that makes user research scale. It provides roles, tools, and processes so researchers focus on insights, not logistics. Teams often assume researchers self-manage operations, which bottlenecks research as companies grow.
Hybrid Model: Core Team Plus Federated Contributors
A hybrid design system team pairs a central group owning primitives with product squads shipping patterns. Large orgs use it when one team cannot cover every surface. It fails when contribution rules are vague and the core becomes a bottleneck not an enabler.
How does management evolve in scaled agile versus traditional program management?
This tests whether you see scaled agile shifting management from command to enablement. A strong answer contrasts LeSS manager-as-teacher supporting self-managing teams against traditional program-management command structures.
What is a Scrum of Scrums purpose and what technical info is shared?
Multi-team sync for blockers, dependencies, API changes, integration risks; not a status meeting. Cross-team coordination in scaled Scrum. Treating it as a lead standup with PM-style updates.
Get Scaling bites daily.
Five a day, five minutes, offline. With quizzes so it sticks.
Open testing — you’ll join as an early tester.