The main factor is how data is encoded and transported. gRPC typically uses Protocol Buffers, a compact binary format, which keeps message sizes small and speeds up parsing compared to JSON. Smaller payloads mean less serialization work and lower network bandwidth, which can lead to higher throughput in benchmarks. In addition, gRPC runs over HTTP/2, offering features like multiplexed streams and header compression, which further improves efficiency and latency. The statement that gRPC uses JSON by default is a misconception; gRPC uses Protocol Buffers by default, while REST commonly uses JSON.

Health checks verify that each backend server can actually handle requests. The load balancer periodically probes the servers, and if a server fails the probes consistently, it is taken out of the traffic rotation so new requests aren’t sent to it. This automatic removal of unhealthy servers keeps the service available by avoiding failed nodes, and once a server recovers, it can rejoin the rotation. The other options aren’t the primary role of health checks. Checking client device health isn’t something the load balancer does. DNS failover is a separate mechanism for directing traffic at a higher level, not about monitoring individual backends. SSL certificate validity isn’t the core function of health checks, though some systems can monitor cert expiry, it’s not what the health check primarily accomplishes.

The idea is to manage cache capacity using multiple, practical signals rather than a single metric. Scale when you’re genuinely approaching the limits or when demand is high, so you keep performance from degrading. If memory usage climbs above 80%, you’re near the memory cap and eviction pressure rises, so adding capacity helps. If the workload pushes throughput beyond a high threshold (like 100k ops/sec), the cache is under heavier use and may start showing latency or miss penalties unless you scale. If latency is already very good (below 0.5 ms), you have headroom to scale ahead of expected growth to preserve that fast response as traffic increases. Using these combined conditions helps ensure scaling happens in response to real pressure and also in anticipation of rising load, rather than based on a single metric that might mislead.

Sharding with a directory means you keep a central lookup structure that maps each shard key to the specific shard, and every query first consults that directory to route to the right shard. This setup offers flexibility because you can reassign data or rebalance shards by updating the directory without changing application logic. The trade-offs are clear: you pay extra latency for the directory lookup on every query, and there's a potential single point of failure if the directory becomes unavailable or bottlenecks the system. Understand how the others differ: range-based sharding assigns contiguous key ranges to shards directly, which is simple and fast for routing but harder to adapt when you need to rebalance or add shards. Consistent hashing uses a hashing ring so keys map to shards with minimal movement when the topology changes, avoiding a central directory and thus reducing rebalancing work. Two-phase commit is about coordinating transactions across multiple shards and can add latency due to coordination overhead, but it doesn’t define how shard assignments are stored or routed.