What Tencent Backend Engineers Earn and How to Nail Their Interview

Tencent Backend Interview Technical Topics

Redis Caching Optimization

Redis improves performance by intercepting hot data before it reaches the database and by caching the results of expensive computations or cross‑service queries, thereby reducing response latency and database load.

Typical use cases include homepage feeds, product details, user profiles, feature flags, and aggregated statistics.

The most common pattern is cache‑aside : read from Redis first; on a miss, read from the database, return the result, and populate Redis with a reasonable TTL.

For writes, update the database first and then delete the related cache key to avoid stale data. This approach favors eventual consistency.

Cache‑Database Consistency Strategies

Read using cache‑aside; on write, update the DB and then delete the cache. If cache deletion fails, retry via a message queue or by subscribing to the MySQL binlog (e.g., using Alibaba’s Canal) and processing delete operations asynchronously.

Message‑queue retry flow:

After a successful DB update, enqueue a cache‑deletion task.

A consumer reads the task and attempts to delete the cache.

If deletion fails, the task is re‑queued for a limited number of retries; after exhausting retries, an alert is raised.

Binlog subscription flow:

Enable MySQL binlog and run Canal as a pseudo‑slave to receive change events.

Parse the binlog to extract the affected rows/keys.

Publish delete‑cache events to a MQ; downstream consumers delete the corresponding Redis keys.

Both approaches achieve eventual consistency while keeping the write path simple.

Identifying Hot Keys

Direct Redis tools: redis-cli --hotkeys (requires maxmemory-policy set to LFU) scans the instance and reports keys with the highest access frequency. MONITOR streams every command in real time; useful only in test environments because of its heavy performance impact.

Production‑grade practice is to instrument the application layer: each cache access increments a local counter; counters are periodically aggregated and pushed to a monitoring system. A sliding‑window algorithm can flag keys whose access rate exceeds a configurable threshold, triggering alerts or automatic mitigation (e.g., local in‑process cache, Redis cluster sharding, or static configuration push).

MySQL Transaction ACID Properties

Atomicity : All statements in a transaction succeed or all are rolled back.

Consistency : Data remains valid before and after the transaction.

Isolation : Concurrent transactions do not interfere; implemented via MVCC or locks.

Durability : Committed changes survive crashes.

In InnoDB, redo logs guarantee durability, undo logs guarantee atomicity, and MVCC provides isolation.

MySQL Performance Tuning

Analyze queries with EXPLAIN and optimize slow statements.

Create appropriate indexes (single‑column, composite, respecting left‑most prefix).

Avoid index‑ineffective patterns (e.g., leading wildcards in LIKE, functions on indexed columns).

Prefer covering indexes and avoid SELECT * when possible.

Rewrite deep pagination, e.g., SELECT * FROM tbl WHERE id>20000 LIMIT 10 instead of LIMIT 20000,10.

Implement read‑write splitting with master‑slave replication.

Consider sharding large tables or separating frequently accessed columns.

Introduce a caching layer (Redis) while handling cache consistency as described.

SQL Injection Prevention

SQL injection occurs when untrusted input is concatenated into SQL statements without proper sanitization.

Validate and escape user input.

Use parameterized queries or prepared statements.

Grant the database user only the minimum required privileges.

Apply input filtering to block malicious patterns.

HTTP vs HTTPS

HTTPS adds SSL/TLS encryption between TCP and HTTP.

HTTPS requires an additional TLS handshake after the TCP three‑way handshake.

Default ports: 80 for HTTP, 443 for HTTPS.

HTTPS needs a certificate from a trusted Certificate Authority.

API Timeout Troubleshooting

Typical workflow:

Determine whether the timeout is intermittent or persistent; collect request IDs or timestamps.

Check monitoring dashboards for response time, QPS, error rate, and resource utilization (CPU, memory, network).

Inspect logs for slow database queries, cache miss spikes, downstream service latency, network packet loss, DNS delays, or recent code releases.

Look for JVM Full GC pauses or container throttling.

Based on the root cause, apply the appropriate fix (add indexes, scale resources, enable circuit breaking, adjust cache TTL, etc.) and perform a post‑mortem.

Microservice Architecture Overview

Microservices decompose a monolithic application into independent services, each owning a specific business capability and its own data store.

Benefits:

Independent deployment and scaling.

Technology heterogeneity per service.

Challenges and essential components:

Service discovery (e.g., Nacos, Eureka).

RPC/REST communication (Dubbo, gRPC, Feign).

Load balancing, fault tolerance (circuit breaking, retries).

Distributed tracing (SkyWalking, Zipkin).

Centralized configuration management.

API gateway (Spring Cloud Gateway, Nginx).

Distributed transactions (Seata, TCC, SAGA).

Migrating a Monolith to Microservices

Adopt domain‑driven design to define service boundaries, then extract low‑risk modules incrementally.

Typical steps:

Map existing modules and dependencies; identify loosely coupled domains.

Set up infrastructure: registration center, config center, and gateway.

Start with a single shared database, using separate schemas per service; later split into physical databases.

Replace direct method calls with remote calls (Dubbo, Feign) and introduce asynchronous messaging where appropriate.

Ensure thorough testing, gray releases, and rollback plans for each extracted service.

Algorithm Exercise – Top‑k Frequent Strings

Find the k most frequent strings in a dataset (the classic “top‑k” problem). Common solutions include using a hash map to count frequencies followed by a min‑heap of size k to keep the top entries.