Notes from Reddit
API Gateway as an entrypoint to a lambda-based API
API Gateway could handle auth and routing, leaving the lambda to just handle processing.
https://www.reddit.com/r/dotnet/s/Y7lcJt7D8p
Look into minimal APIs in ASP.NET Core. You need virtually nothing other than the endpoints that do the work. The API gateway basically acts as a reverse proxy, so the API is never directly exposed to the public and thus doesn’t need anything like auth components.
It’s actually an extremely efficient design. All your cruft like auth is centralized and configuration based, whereas the actual code that needs to be compiled and run in containers is the bare minimum and explicit to the purpose of the service and nothing else. This means you get faster, smaller builds and build time and artifact size can be a huge concern in large deployments.
https://www.reddit.com/r/dotnet/s/pioWmy4Tm9
It’s definitely more common to proxy api gateway to lambda for a dotnet app. Slow starts aren’t the problem they used to be, but the aspnet middleware pipeline is really powerful (and means you only need to make minimal application changes if you change how or where you host the application).
The “lambda per route” in api gateway is a common pattern, and something which is sort of encouraged if you play around in the api gateway console. That said its more common when used with something like nodejs where cold start is really not an issue
https://www.reddit.com/r/dotnet/s/UNyHqQtZqp
20 System Design Q&A questions you should know @rauljuncoV
Fundamentals
Q: What’s the difference between horizontal and vertical scaling?
A: Vertical scaling adds resources to a single machine (CPU, RAM). Horizontal scaling adds more machines and distributes load. Vertical is simpler but limited; horizontal is harder but scales better.
Q: What is a load balancer, and why is it important?
A: A load balancer distributes incoming requests across multiple servers to improve availability, performance, and fault tolerance.
Q: What’s the CAP theorem?
A: The CAP theorem states that a distributed system can only guarantee two of Consistency, Availability, and Partition Tolerance. Partition Tolerance is non-negotiable, so the real tradeoff is between C and A.
Q: What’s the difference between strong and eventual consistency?
A: Strong consistency means every read sees the latest write. Eventual consistency means reads may lag but converge to the latest state over time.
Data & Storage
Q: When should you use a SQL database vs. NoSQL?
A: SQL is ideal for structured data, relationships, and transactions (ACID). NoSQL fits flexible schemas, large-scale, and high write throughput.
Q: What is database sharding?
A: Database sharding splits a database into smaller parts (shards) distributed across servers to scale writes and reads.
Q: What’s a covering index and when is it useful?
A: An index that contains all the columns needed by a query, avoiding table lookups. It speeds up frequently repeated queries. See indexes and query planning for the three-star model and why the optimizer, not the index, has the final say. Concurrency control is its own topic — see concurrency and locks.
Q: What’s a cache, and what are common cache invalidation strategies?
A: A cache stores frequently accessed data in memory for speed. Strategies include TTL (time-to-live), write-through, and explicit invalidation.
Reliability & Scaling
Q: What’s the difference between synchronous and asynchronous processing?
A: Sync means request/response happens immediately — the caller blocks until the work is done. Async decouples producers and consumers: work is handed off (often via a message queue) and processed later, so the caller isn’t blocked. Async improves throughput and resilience to spikes at the cost of added complexity and eventual, rather than immediate, results.
Q: What are message queues used for?
A: Message queues decouple services, handle spikes, ensure reliability through retries, and enable async workflows.
Q: What is idempotency, and why does it matter?
A: An operation is idempotent if multiple executions have the same effect as one. It prevents duplication issues in retries or failures.
Q: How do you design for fault tolerance?
A: Eliminate single points of failure through redundancy and replication, and fail over to healthy instances behind a load balancer. Contain failures with timeouts, retries (with backoff), circuit breakers, and bulkheads, and degrade gracefully rather than collapsing. Make retried operations safe with idempotency, and decouple components with message queues so a slow or failed consumer doesn’t take down producers.
Performance & Availability
Q: What’s a CDN, and why use it?
A: A Content Delivery Network caches static content geographically closer to users, reducing latency and load on origin servers
Q: How do you handle rate limiting?
A: Use token bucket or leaky bucket algorithms, enforced at gateways or distributed caches, to prevent abuse and ensure fair usage.
Q: What’s the difference between vertical partitioning and horizontal partitioning?
A: Vertical splits by columns (different features in different DBs). Horizontal splits by rows (different users/regions). Sharding is a form of horizontal partitioning.
System Design Scenarios
Q: How would you design a URL shortener (like bit.ly)?
A: Core: hash IDs, database for mapping, cache hot entries, handle collisions, CDN for static redirects.
Q: How do you design a rate-limited login system?
A: Use Redis for counters with TTL, track attempts per IP/user, enforce exponential backoff or captcha after thresholds.
Q: How would you design a feed system (like Twitter timeline)?
A: Options: Fan-out on write (push posts to followers’ timelines) or fan-out on read (pull from sources on demand). Tradeoff: write-heavy vs. read-heavy optimization.
Q: How do you ensure exactly-once processing in a distributed system?
A: Combine idempotency with deduplication (e.g., unique request IDs + Redis), or use transactional outbox/event sourcing.
Q: How would you monitor a large-scale distributed system?
A: Collect logs, metrics, traces (via OpenTelemetry, Prometheus, Sentry, etc.), set up dashboards/alerts, define SLis and SLOs.