Scalability
64 bites tagged Scalability — interview questions with model answers, and 60-second explainers.
Governance for accessibility regressions
Detection via audits and monitoring, triage with severity and ownership, remediation SLAs, prevention feedback. a repeatable a11y governance loop across consuming products.
How do you reliably deliver a survey to 10,000 users?
Tests systems thinking for outreach at scale. Strong answers cover idempotent delivery, rate-limited async sending, PII handling and retention, plus observability into delivery and response rates.
Super button versus composition: discuss trade-offs and scalability
Tests combinatorial explosion and API trade-offs in design systems. Contrast the super button's exponential growth with composition's explicit APIs and linear scalability, noting governance needs. Red flag: absolutism or ignoring type safety and tree-shaking.
Is Tailwind maintainable at scale, and what patterns support your claim?
Tests your CSS architecture judgment with utility-first scaling patterns. Strong answers pick a side, citing three patterns: strict tailwind config, components hiding class soup, and sparing @apply.
Propose a scalable entitlement architecture for complex rules
Tests separation of hot-path reads from async policy work. Great answers: edge-cache plan tokens; stream quota usage async; isolate rules in a microservice. Red flag: doing a DB lookup or sync quota check per request.
How would you out-engineer a competitor's new data-intensive feature?
This tests strategic design under competition. Strong answer maps competitor's bottleneck, applies distributed sharding or streaming, picks asymmetric edge caching, and locks in latency SLAs. Red flag: no bottleneck analysis or ignoring quantified moats.
Design a real-time personalized notification trigger system
Stream events to a delayed queue, expose a rule UI to non-technical users, and deliver idempotently. Event-driven scheduling with backpressure. Cron polling a database without ordering or rate limits.
Compare fan-out-on-write vs fan-out-on-read for an activity feed
Tests whether you tie feed architecture to read/write ratios and follower distribution. Strong answers contrast push O(1) reads with celebrity storms against pull O(1) writes with read amplification, then propose a hybrid threshold.
EndpointSlice: Splitting the Monolithic Endpoints List
EndpointSlice shards a service's pod backends into smaller chunks instead of one massive list. This keeps kube-proxy and DNS fast when services scale to thousands of pods. Do not edit them by hand; the controller owns them and will overwrite your changes.
Replace a hardcoded error message with a scalable copy system
Tests decoupling UI copy from code via key-based i18n. Move the string into a JSON namespace, wire through i18next, load dynamically, and lint against hardcoded strings. Manual find-and-replace without keys or fallback is a red flag.
Design a scalable documentation system for three engineering teams
Tests prioritization and process design for a sole writer supporting three engineering teams. Strong answers use tiered intake with SLAs, a public Kanban board, and async status updates. Red flag: ad-hoc prioritization through Slack DMs with no queue.
Build a system to send 1M personalized emails in 2 hours
This tests async distributed throughput and deliverability. Cover partitioned queues, auto-scaling workers, per-ESP rate limits, IP rotation, and exponential backoff with dead-letter queues. Red flags: synchronous sends, skipping IP warmup, or no retry logic.
How would you architect personalized email and coupon delivery at scale?
This tests decoupled rendering and atomic coupon reservation. A strong answer uses template rendering, atomic coupon reservation, an idempotent queue, and batched ESP delivery. Red flag: generating coupons during SMTP without reservation risks overspend.
Design a highly scalable headless CMS architecture
Tests write-heavy authoring versus read-heavy delivery separation at scale. Strong answers outline dual-cluster isolation, event-driven invalidation, and CDN edge caching. Red flag: a monolithic service with only database query caching.
What is Twelve-Factor's config recommendation for CI/CD and scalability?
Tests Factor III and CI/CD scaling implications. Strong answer: config lives in env vars, never in code, so one build promotes across stages and new instances start with correct context immediately. Red flag: config files checked into version control.
Load Balancing Algorithms: How to Pick a Server
Load balancing algorithms are the rules a client uses to pick one server from a pool of identical backends. They're used by web proxies routing user traffic and by microservices calling each other.
Capacity Planning: Don't Run Out of Room
Capacity planning matches your system's resources to user demand, crucial for handling traffic spikes or budgeting cloud spend. The main footgun is planning for theoretical 'design capacity' instead of realistic 'effective capacity' which accounts for…
Data Sharding: Splitting a Database for Scale
Sharding splits a huge database into smaller, independent databases (shards), each on its own server. It's like giving different volumes of a phone book to different librarians. This is critical for massive datasets, but a bad shard key creates 'hot spots'.
Rate Limiting: Your API's Bouncer
Rate limiting acts as a bouncer for your API, controlling traffic to protect your service. It's used on public APIs to prevent abuse, ensure fair usage, and defend against denial-of-service attacks.
Universal Scalability Law: The Physics of Scaling
The Universal Scalability Law (USL) models throughput by quantifying the two costs of parallelism: contention and coherency. Use it to forecast performance and diagnose bottlenecks.
Amdahl's Law: The Bottleneck of Parallel Speedup
Amdahl's Law shows a system's speedup is limited by its sequential parts. If 10% of a task must run serially, your maximum speedup is 10x, no matter how many cores you add. This applies to CPUs, databases, and distributed jobs.
Go's Design Philosophy: Engineering Over Novelty
Go's design philosophy is engineering over novelty, built to solve Google's problems with slow builds and complexity in massive codebases. It excels at large, networked systems where maintainability and fast compilation are critical.
Immutable Secrets & ConfigMaps: Write-Once Configuration
Treat your Kubernetes configuration like a container image: create it once, then create a new version to update it. The `immutable` flag enforces this "write-once" pattern for Secrets and ConfigMaps, reducing API server load and preventing accidental updates.
Reduce Time-to-Market with a Design System
A design system is a shared toolkit of pre-built UI components, not just a style guide. It lets teams build interfaces from a library of pre-coded parts, drastically cutting repetitive work. The footgun is treating it as a static document, not a living system.
Get Scalability bites daily.
Five a day, five minutes, offline. With quizzes so it sticks.
Open testing — you’ll join as an early tester.