Product Manager · AVA · HTTPS

10 Backend Requirements That Turned Simple Promises Into System-Wide Re-architectures

By 吴琼琼 · Jul 27, 2026

Read original on juejin.cn ↗ Google Translate ↗ Alt translation

These anecdotes map directly onto the cost centers that Western engineering teams face: scope creep that turns a UI tweak into a platform project, performance targets that silently trade latency for infrastructure spend, and compatibility hacks that outlive the original stakeholder. Recognizing the pattern early is what separates a one-sprint task from a quarter-long migration.

Summary

A single API that must serve both paginated and unpaginated responses in different formats, a soft-delete scheme with four order-type-specific retention rules, and a 1-million-row Excel export that became an async zip-and-email pipeline. These are the real-world requirements that landed on one backend team over five years, each starting with a casual phrase like “this is simple” or “just make it compatible.”

The pattern is consistent: a seemingly small UI or data ask exposes missing infrastructure. A 200ms page-load target forces a shift from serial microservice calls to parallel async execution backed by a Redis-plus-local-cache tier that raises hosting costs 30%. A slow SQL query morphs into an Elasticsearch deployment with Canal-based change data capture. A request to open an API to 20 merchants turns into a database-backed, approval-gated field-permission system.

Each story ends with a twist: the original requirement gets abandoned, the client admits they only needed three months of data, or the CTO shelves the migration after a production incident. The accumulated complexity, however, stays in the codebase.

Takeaways

— A pagination toggle that also changes the response envelope forces a fork in the API contract; the cleanest exit is often to deprecate the old format and unify on one.

— Soft-delete rules that vary by entity type (flash sale, group buy, member) require a state machine, not a boolean flag, and the cleanup cron will lock tables unless batched by indexed ranges.

— Excel exports above 100k rows need an async job that splits into multiple files, zips them, and notifies the user; the 1,048,576-row Excel limit is a hard ceiling.

— Meeting a 200ms p99 across three microservices demands parallel async calls and a two-tier cache; the latency win is real but the Redis and local-cache footprint adds 30% to compute cost.

— Supporting both GET and POST on one endpoint with different parameter locations creates a silent failure mode when Content-Type and annotation mismatch; a single contract and an API version bump are safer.

— Field-level data masking needs a registry of sensitive fields and a masking strategy per type; a wrong mapping can turn a real name into asterisks and generate user-facing bugs.

— A “simple button” that depends on login recency, VIP status, order count, balance, dismissal preference, and gender-based copy is a feature-flag and eligibility-engine problem, not a UI tweak.

— Replacing OR with UNION in MySQL can cut query time from seconds to hundreds of milliseconds, but a 10ms target on a 50-million-row table forces a move to Elasticsearch and a CDC pipeline.

— Per-merchant field-level API permissions that start as a hardcoded map inevitably become a database-driven configuration with an approval workflow; plan for the admin UI from day one.

— MySQL-to-MongoDB migration without downtime requires dual writes, a reconciliation job, and a fast rollback path; a single shard failure in the shadow database will force an emergency cutback to the old primary.

Conclusions

Every story follows the same arc: a trivial-sounding request, a hidden matrix of conditions, an engineering solution that adds real infrastructure cost, and a post-launch revelation that the original ask was overstated or abandoned. The code and the cloud bill outlive the requirement.

The 200ms anecdote exposes a common organizational asymmetry: the product manager claims the latency win while the infrastructure cost lands on a different budget line, so the trade-off is never evaluated as a business decision.

Several of these requirements are really symptoms of missing platform capabilities: a field-permission engine, an async export service, a feature-flag system. Once built for one “simple” request, they become reusable, but the first project always pays the full tax.

The MongoDB migration story is a textbook example of resume-driven architecture: a technology choice pushed from the top without a clear problem statement, implemented under a deadline, and abandoned after the first production incident.

Concepts & terms

Soft delete

Marking a database row as deleted via a flag (e.g., is_deleted=1) instead of physically removing it, so the data remains queryable by the backend while being hidden from the user-facing application.

Two-tier cache

A combination of a local in-process cache (fastest, but per-instance) and a distributed cache like Redis (shared across instances). The local cache absorbs the hottest reads; Redis provides consistency across nodes.

Dual-write pattern

Writing data to two databases (e.g., MySQL and MongoDB) simultaneously during a migration, then running a reconciliation job to detect and repair any inconsistencies between them.

Change Data Capture (CDC)

Capturing row-level changes from a database’s transaction log and streaming them to other systems. Tools like Canal (for MySQL) feed data into message queues or search indexes such as Elasticsearch.

From the discussion

The discussion splits between gallows-humor commiseration and dismissive pragmatism. One side escalates the article's premise with an even more absurd real-world demand: a solo rebuild of an entire enterprise collaboration suite in two months. The other side shrugs off the complexity, suggesting AI will absorb future pain or that specific technical requests are trivial to accommodate.

— Product demands can far exceed the article's examples, such as being ordered to single-handedly replicate a massive SaaS platform like Feishu on an impossible timeline.

— The expectation that AI will eventually handle these unreasonable requests, sparing engineers from the fallout.

— Some requirements that appear system-shattering, like dual HTTP method support, are dismissed as trivial to resolve with a simple additional endpoint.