The Underrated Engineering Behind Rating Systems

I believe the rating section in most applications such as (Bookings.com, Amazon, Uber) is highly underrated. Most people see it as straightforward, but capturing this information at scale can be both challenging and frustrating. Many business products especially service-based applications rely heavily on ratings, but making this system coherent is strenuous.

Why is this important? Consumer decisions are often driven by the quality of service, which is reflected in these ratings. From a technical perspective, this system must be highly available and low-latency. To talk numbers: let’s aim for a P99 of 50ms with peak traffic of 10k RPS (Requests Per Second).

To accommodate this, we need an efficient caching mechanism and pre-materialized views on a relational DB (meaning all necessary joins are performed beforehand).

Calculating the Scale Imagine we have 500 million reviews in total across all products. If each review is roughly 2KB, we are looking at 1TB of data. While 1TB isn't massive by modern standards, hitting a single-node PostgreSQL or MongoDB instance with 10k GET requests per second would likely lead to a system crash. To solve this, we shard the database. Imagine 5 master nodes, each with 2 replicas—giving us 5 write nodes and 10 read replicas. To ensure High Availability (HA), these replicas should be placed in different Availability Zones (AZ) so that an infra failure in one zone doesn't impact the business.

The Routing Problem How does the system know which DB node holds User A’s data? A naive approach is a simple hash function using a deterministic number to route requests. However, in large systems, cost and scalability are concerns. If your user base grows or shrinks by 40%, a fixed hash function is hard to scale because it requires massive data re-sharding.

This is where Consistent Hashing comes in. Avoiding the jargon: instead of a direct mapping, we use a "circular" range (the hash ring). Imagine a loop from 0 to 100. If you have two nodes, one might cover 0–50 and the other 50–100. If a request hash is 26, it goes to the first node. If you need to add a third node (e.g., at 75), you only need to move the data falling between 50 and 75. In the big picture, the amount of data moved is minimized, which is a huge win for system stability.

Even with efficient sharding, we have to consider "Hot Keys." Imagine a major product launch where a single item's reviews are fetched redundantly millions of times. Even with sufficient read replicas, every database operation adds latency and puts a load on your disk I/O.

Caching helps mitigate this issue. Using a CDN for static content or Redis for frequently accessed review data allows you to serve these requests from memory rather than hitting the database. This drastically reduces the load on your primary storage and ensures that a single popular product doesn't bring down your entire sharded architecture.

Conclusion A combination of consistent hashing, smart caching, and distributed data can solve the majority of scaling headaches. Follow for more—I am Aadinir.