High-concurrency workloads — flash sales, live broadcasts, real-time game state — can overwhelm relational databases in seconds. Tair (Redis OSS-compatible) is a managed in-memory data store that keeps response times consistent under these conditions.
Gaming, e-commerce, and livestreaming are three industries where this architecture addresses common performance and availability challenges.
Scenario overview
| Pattern | Typical industries | What Tair provides |
|---|---|---|
| Caching layer in front of a relational database | Gaming, e-commerce | Absorbs read traffic; backend databases handle writes |
| Primary storage for frequently updated state | Gaming | Master-replica redundancy with automatic failover |
| High-concurrency request absorption | E-commerce, livestreaming | In-memory throughput that backend databases cannot sustain |
| Real-time data store for large concurrent audiences | Livestreaming | Low-latency reads at scale, with online scaling |
Gaming industry applications
Tair functions as a core component for both caching and data persistence in gaming backends.
Scenario 1: caching layer in front of a relational database
Deploy Tair as a caching service between your application and ApsaraDB RDS. Data is stored in backend databases (ApsaraDB RDS instances), keeping frequently accessed data served from Tair in memory.
Scenario 2: primary storage for game state
For simpler architectures where the main game server runs on Elastic Compute Service (ECS), store business data directly in a Tair instance. Tair's master-replica architecture provides redundancy. The master node handles all traffic, and if it fails, the system automatically switches workloads to the replica node. The failover process is transparent to your application.
E-commerce industry applications
Tair is widely used in the e-commerce industry for business scenarios such as flash sales and recommendation. Tair handles the traffic patterns that overwhelm relational databases during peak sales events.
Scenario 1: flash sales and high-traffic promotions
An online shopping system is likely to be overwhelmed by user traffic during large promotional activities such as flash sales. Store product and session data in Tair to absorb the load — Tair's in-memory architecture handles the concurrency that backend databases cannot sustain during large promotional events.
Scenario 2: inventory management
Store commodity data in ApsaraDB RDS and inventory data in Tair. Not all queries are forwarded to ApsaraDB RDS — inventory queries are served from Tair directly. This keeps response times consistent and prevents the database from becoming a bottleneck during high-concurrency stocktaking operations.
Livestreaming applications
Livestreaming platforms use Tair to store user data and chat records, where latency and scalability requirements are most demanding.
High availability
The master-replica architecture keeps the service available if a node fails, which is critical when thousands of concurrent viewers depend on real-time data.
High performance
Cluster instances distribute workloads across multiple shards, bypassing the single-threaded limitation of open-source Redis. This allows Tair to handle the sudden traffic spikes that occur when viewership surges during a broadcast.
High scalability
Scale instances up or down with a few clicks. The scaling process is fully transparent to users.