Unlock Shopee Backend Interview Secrets: Core Concepts & Practical Tips

Shopee recently announced generous salary offers (up to 32k base plus signing bonuses) for backend positions in Shanghai, Beijing, and Shenzhen, prompting many candidates to discuss interview difficulty and process.

The interview follows a typical big‑tech flow: technical fundamentals, project experience, and algorithm questions, with a strong focus on backend component principles.

Network

HTTP vs HTTPS

HTTP transmits data in plain text, while HTTPS adds SSL/TLS between TCP and HTTP for encryption.

HTTPS requires an extra handshake after TCP three‑way handshake.

Default ports: 80 for HTTP, 443 for HTTPS.

HTTPS needs a digital certificate from a CA.

Rate‑Limiting Algorithms

Rate limiting ensures system stability under high concurrency by restricting excess requests.

Fixed Window : Simple counting within a fixed time window; can cause traffic spikes at window boundaries.

Sliding Window : Improves fixed window by sliding smaller time slices, smoothing traffic.

Leaky Bucket : Shapes traffic to a constant rate but cannot handle bursts.

Token Bucket : Allows controlled bursts while maintaining a steady output rate.

Fixed Window Algorithm

Fixed window counts requests in a set interval; if the count exceeds the threshold, requests are dropped. When the window ends, the counter resets.

Example: with a 1 s window and limit 100, 100 requests arriving at 999 ms all pass, and another 100 at 1 ms pass, resulting in 200 requests in 2 ms.

Sliding Window Algorithm

Sliding window divides the interval into smaller slices and moves across time, applying the fixed‑window logic within each slice to avoid double‑counting.

Leaky Bucket Algorithm

Simulates water flowing through a hole; excess inflow overflows, providing a smooth outflow but cannot handle bursts efficiently.

Token Bucket Algorithm

Tokens are added to a bucket at a fixed rate; a request proceeds only if a token is available, allowing limited bursts.

Java

Why Use Thread Pools?

Thread pools reduce the overhead of creating and destroying threads. They consist of core threads, a maximum size, and a task queue. Tasks are executed by core threads first; if full, they queue or spawn additional threads up to the maximum, after which a rejection policy applies.

Thread Pool Parameters

corePoolSize : Number of core threads that stay alive even when idle.

maximumPoolSize : Upper limit of threads.

keepAliveTime : Time after which excess idle threads are terminated.

unit : Time unit for keepAliveTime.

workQueue : Queue for pending tasks.

threadFactory : Creates new threads, can set names.

handler : Rejection policy when the queue is full.

Common Thread Pool Types

ScheduledThreadPool – periodic tasks.

FixedThreadPool – fixed number of threads.

CachedThreadPool – unbounded threads with SynchronousQueue.

SingleThreadExecutor – single thread, preserves task order.

SingleThreadScheduledExecutor – single‑thread scheduled executor.

Redis

Memory Eviction Policies

Configured via maxmemory in redis.conf. Policies include:

noeviction : No eviction; writes fail when memory is full.

volatile‑random : Randomly evicts keys with an expiration.

volatile‑ttl : Evicts keys with the nearest expiration.

volatile‑lru : Evicts least‑recently‑used expiring keys.

volatile‑lfu : Evicts least‑frequently‑used expiring keys.

allkeys‑random : Random eviction of any key.

allkeys‑lru : Evicts least‑recently‑used keys.

allkeys‑lfu : Evicts least‑frequently‑used keys.

Expiration Deletion Strategies

Redis uses a combination of lazy deletion and periodic deletion.

Lazy Deletion Implementation

int expireIfNeeded(redisDb *db, robj *key) {<br/>    // check if key is expired<br/>    if (!keyIsExpired(db,key)) return 0;<br/>    ...<br/>    /* delete expired key */<br/>    ...<br/>    // async delete if server.lazyfree_lazy_expire == 1<br/>    return server.lazyfree_lazy_expire ? dbAsyncDelete(db,key) : dbSyncDelete(db,key);<br/>}

Before accessing or modifying a key, Redis calls expireIfNeeded to remove it if expired.

Periodic Deletion Process

Every second Redis performs 10 active expiration cycles, each randomly sampling 20 keys from the expiration dictionary. If more than 25% of sampled keys are expired, the cycle repeats, but each cycle is limited to 25 ms.

do {<br/>    expired = 0;<br/>    num = 20;<br/>    while (num--) {<br/>        // sample a key, check expiration, delete if needed, increment expired<br/>    }<br/>    if (timelimit_exit) return;<br/>    /* repeat if expired > 20/4 */<br/>} while (expired > 20/4);

MySQL

Isolation Levels

Read Uncommitted : Uncommitted changes are visible.

Read Committed : Changes become visible after commit.

Repeatable Read : Consistent snapshot for the whole transaction (default InnoDB).

Serializable : Full locking, transactions execute one after another.

Index Structures

Indexes can be classified by data structure (B+Tree, Hash, Full‑text), storage (clustered vs secondary), field characteristics (primary, unique, normal, prefix), and column count (single vs composite).

B+Tree stores data only in leaf nodes and links leaves with a doubly linked list, making range queries efficient.

Why B+Tree?

B+Tree vs B‑Tree : Smaller node size, fewer I/O operations.

B+Tree vs Binary Tree : O(log d N) vs O(log N) with d ≫ 2.

B+Tree vs Hash : Hash is O(1) for equality but unsuitable for range queries.

MVCC for Repeatable Read

InnoDB creates a Read View at transaction start; records are visible based on their trx_id relative to the view's min_trx_id and max_trx_id, and the list of active transaction IDs ( m_ids).

Slow Query Optimization

Use EXPLAIN to ensure indexes are used.

Create covering composite indexes.

Avoid index‑ineffective patterns (left‑wildcard, functions).

Drive large tables with small indexed tables.

Convert deep pagination to range queries (e.g., WHERE id>20000 LIMIT 10).

Split wide tables into narrower ones.

Redo Log vs Binlog

Scope : Binlog is server‑level, redo log is InnoDB‑level.

Format : Binlog formats – STATEMENT, ROW, MIXED; redo log is physical.

Write Method : Binlog appends; redo log overwrites in a circular buffer.

Purpose : Binlog for replication & backup; redo log for crash recovery.

Message Queue (RocketMQ)

Distributed Transaction Handling

RocketMQ implements eventual consistency. The flow:

Producer sends a Half Message (cannot be consumed).

Producer executes local transaction.

Based on transaction outcome, Producer sends Commit (message becomes consumable) or Rollback (message deleted). If uncertain, RocketMQ performs a transaction check.

If the consumer side fails after a commit, RocketMQ retries; persistent failures are logged for manual handling.

Message Ordering

Order is guaranteed per MessageQueue: producers send ordered messages to the same queue, and consumers lock the queue to consume sequentially.

Backlog Mitigation

Scale consumer instances.

Temporarily degrade non‑critical services to reduce load.

Open‑Source Projects & Resources

Useful open‑source projects Boot project: https://github.com/macrozheng/mall Cloud project: https://github.com/macrozheng/mall-swarm Video tutorials: https://www.macrozheng.com/video/

These projects demonstrate a SpringBoot 3 + Vue e‑commerce system with micro‑service architecture, Docker, and Kubernetes deployment.