What Pinduoduo’s Java Backend Interview Really Tests: Redis, MQ, Locks & More

Pinduoduo (First Round) Technical Interview Overview

1. Redis Use Cases for Business Optimization

Redis is a high‑performance in‑memory database capable of handling up to 100K operations per second. It can cache MySQL query results, dramatically reducing database load and improving API response times. For example, an e‑commerce product detail page with 10 million daily visits can store product name, price, and image URL in a Redis HASH (fields product_id, name, price, image_url), cutting response time to under 50 ms and reducing DB queries by 80%.

Another scenario is a news platform that shows a hot‑article list. By storing article IDs in a Redis ZSET sorted by click count and refreshing every five minutes, the front‑end can fetch the ranked IDs directly from Redis, then batch‑query the DB, achieving a four‑fold speedup and a 60% drop in DB connections.

2. Why Redis Handles High Concurrency Easily

Redis processes all client requests in a single thread using non‑blocking I/O multiplexing (epoll/kqueue), eliminating context‑switch overhead and lock contention.

All data resides in memory, so reads/writes take only 100‑300 ns, which is over 100 000× faster than disk I/O.

Redis supports master‑slave replication, Sentinel failover, and sharding clusters, providing high availability and horizontal scalability.

3. How Redis Remains Fast with a Single‑Thread Model

Most operations are performed entirely in memory with efficient data structures, making CPU rarely the bottleneck.

The single‑threaded design avoids lock competition, reducing context‑switch cost and eliminating deadlocks.

I/O multiplexing allows one thread to handle thousands of socket connections simultaneously.

4. ZSet vs. Hash: Typical Scenarios and Characteristics

ZSet provides strict ordering by score and is ideal for leaderboards, video‑play counts, or product‑sales rankings. Hash stores unordered field‑value pairs, suitable for object attributes such as user profiles or product details.

Ordering : ZSet sorted by score; Hash unordered.

Memory usage : ZSet stores value + score (higher memory); Hash stores compact fields.

Typical operations : ZSet supports range queries, ranking, and score‑based retrieval; Hash supports fast field reads/writes and bulk object fetch.

Optimization : ZSet uses an intset (compressed list) when element count ≤128 and each element ≤64 bytes; otherwise it uses a skip‑list plus hash table. Hash switches to a ziplist when the field count is small.

Use cases : ZSet for leaderboards (e.g., game scores, top‑100 videos); Hash for storing user info (name, age, avatar) or product attributes (price, stock, specs).

5. ZSet Underlying Data Structure and Trade‑offs

ZSet is implemented either with a compressed list (now called listpack in Redis 7.0) for small sets or with a skip‑list plus hash table for larger sets. The compressed list offers contiguous memory layout and low overhead but suffers from chain‑update costs when many elements are added or grown, which can degrade performance. The skip‑list provides O(log N) range queries and ordered access with average‑case logarithmic complexity, while the hash table gives O(1) value‑to‑score lookups.

6. Typical MQ Scenarios in Large Systems

Decoupling : Replace synchronous network calls with asynchronous messaging to isolate services.

Asynchronous processing : Off‑load tasks such as order creation, logging, inventory updates, or user‑track insertion to a message queue.

Peak‑shaving : Buffer burst traffic (e.g., flash‑sale spikes) in the queue and consume at a sustainable rate.

7. Push vs. Pull Message Delivery

Push mode has the producer actively send messages to consumers, offering low latency but requiring persistent connections and higher broker CPU load. Pull mode lets consumers poll the broker at their own pace, providing better flow control and lower broker load at the cost of higher latency.

8. When to Prefer Pull Mode

Use pull when you need controllable consumption rates, want to reduce broker resource usage, or when real‑time latency is not critical. Pull also simplifies consumer progress tracking.

9. Fair vs. Unfair Locks

Fair lock (e.g., ReentrantLock backed by AQS queue) guarantees FIFO order, preventing starvation but incurring higher context‑switch overhead and lower throughput.

Unfair lock (e.g., synchronized) allows barging, reduces lock‑acquisition overhead, and yields higher throughput, but can starve low‑priority threads.

10. Multi‑Level Priority Queue Design

Implement separate queues for each priority tier (e.g., high‑priority LinkedBlockingQueue, medium/low ArrayBlockingQueue) with dedicated thread pools. The scheduler always checks the high‑priority queue first; only when it is empty does it process lower tiers. To avoid starvation, introduce aging or promotion mechanisms.

new ThreadPoolExecutor(10, 20, 0L, TimeUnit.MILLISECONDS,
    new LinkedBlockingQueue<>(), new ThreadFactory(){...});

new ThreadPoolExecutor(2, 5, 60L, TimeUnit.SECONDS,
    new ArrayBlockingQueue<>(1000), new ThreadFactory(){...});

11. ThreadPoolExecutor Parameters

corePoolSize

– number of permanent threads. maximumPoolSize – upper limit of thread creation. queueCapacity – maximum length of the waiting task queue.

12. InnoDB vs. MyISAM Index Implementation

Transactions: InnoDB supports ACID transactions; MyISAM does not.

Index structure: InnoDB uses clustered indexes (data stored in primary‑key leaf nodes); MyISAM uses non‑clustered indexes with separate data files.

Lock granularity: InnoDB provides row‑level locks; MyISAM uses table‑level locks.

COUNT(*) performance: MyISAM stores a row‑count variable for O(1) retrieval; InnoDB must scan the table.

13. B‑Tree vs. B+‑Tree Efficiency

Both have O(log N) search complexity, but B+‑Tree stores all data in leaf nodes and links leaves for sequential access, resulting in fewer I/O operations and better range‑scan performance. Insertions and deletions affect only leaf nodes in B+‑Tree, simplifying updates compared to B‑Tree, which may modify internal nodes.

14. Miscellaneous Topics

Technical challenges encountered during learning or internships and the corresponding solutions.

Implementation of the quick‑sort algorithm.