Katkat
Back

Reason About Concurrency, CAP Trade-Offs, and Kubernetes Scaling

J.P. MorganSoftware Engineer II · Onsite
MediumSoftware Engineer IIOnsiteSoftware Engineering Fundamentals

Last updated

This problem tests your understanding of fundamental concurrency concepts, distributed systems trade-offs under partition, and the practical application of Kubernetes scaling mechanisms in a high-throughput environment.

Part 1: Concurrency vs. Parallelism

Explain the distinction between concurrency and parallelism. Provide a specific scenario where a system is concurrent but not parallel, and another where it is both.

Part 2: CAP Trade-offs

You are designing a distributed ledger service that records financial transactions. During a network partition (the 'P' in CAP), the system cannot communicate between two data centers. If you prioritize availability over consistency, what specific risks does this pose to the financial integrity of the ledger? How would you handle conflict resolution once the partition is healed?

Part 3: Kubernetes Scaling Design

You are maintaining a microservice on Kubernetes that processes incoming credit card authorization requests. The service is CPU-intensive and relies on a downstream legacy SQL database that has a hard connection limit of 500 concurrent connections.

  1. Describe how you would configure Horizontal Pod Autoscaler (HPA) to scale these pods based on traffic.
  2. How do you ensure the system does not crash the database during a rapid scale-up event (backpressure management)?
  3. Explain the role of 'readiness probes' in this context; why is it dangerous to have a readiness probe that checks database connectivity during a startup phase?

Hints

Hint 1

Consider that concurrency is about managing multiple tasks at once, while parallelism is about executing multiple tasks at the exact same moment.

Hint 2

When choosing between Consistency and Availability, consider the cost of 'stale reads' versus the cost of 'system downtime' in a financial context.

Hint 3

Think about how to implement a queue or a rate-limiter as a buffer to protect downstream dependencies when the HPA adds new replicas that all attempt to open new connections simultaneously.

Follow-up questions

  • How does the choice of isolation level in your database (e.g., Read Committed vs. Serializable) impact your system's performance during high concurrency?
  • If your service is stateful, how would you change your strategy for Kubernetes scaling compared to a stateless service?
  • What metrics, other than CPU and memory, would be most useful for scaling a latency-sensitive service?