Summary: This discussion centers on what constitutes "good system design," candidly and multidimensionally exploring the gap between ideals and reality in actual development work and system design interviews, and how practicality and complexity collide in the real world. It unpacks, through various anecdotes and advice, how complex systems are often not evidence of good design but rather the result of poor decision-making. Key topics include "the aesthetics of simplicity," "the explanation style demanded in interviews," "ORM and SQL usage," "microservices and shared databases," and "the gap between interviews and actual work."
1. Does Complexity Equal Great System Design?
It begins with an engineer's confession.
"I often feel alone. Engineers look at complex systems and think, 'Wow, what a well-architected system design!' In reality, complex systems often reflect the absence of truly good design."
They note that this kind of realistic awareness can actually count against you in interviews.
"It's important to temporarily forget this during interviews. In fact, I once made a blunder by answering this honestly in a system design interview."
The example of a hypothetical startup app interview question and candidate conversation goes something like this:
Interviewer: "How would you handle backpressure here?" Candidate: "At this QPS, it's not really worth worrying about." Interviewer: "Why wouldn't you use a queue instead of a cron job?" Candidate: "It's not really necessary for this type of app, but I can walk you through the trade-offs." Interviewer: "Would you go with SQL or NoSQL?" Candidate: "It doesn't really matter. Shouldn't we just go with whatever the team is most comfortable with?"
These answers don't score high in actual interview settings.
"What interviewers want is a complex architecture diagram (boxes and arrows) that fills the entire whiteboard. It looks like Kubernetes on top of Kubernetes." 😅
2. System Design Interviews: Signaling vs. Real Signals
There were also many opinions from the interviewer's perspective.
"Drawing on my experience conducting hundreds of system design interviews, (especially for mid-level and above candidates) you need to fully explain your reasoning and the considerations behind your answers. Why you made a particular judgment, and how the choice would differ under different circumstances."
"If a candidate says backpressure is unnecessary, they need to specifically answer when it would become necessary and how they'd apply it then. Good candidates walk through this entire process without being prompted."
"Senior-level candidates, in particular, need to demonstrate initiative by clearly distinguishing which areas they'll dive deep into and what trade-offs exist, discussing them in depth."
3. The Gap Between Real Work and Interviews
Ideally, simplicity is a virtue, but the reality is that there's a culture of demanding or showing off complexity, as evidenced by various anecdotes.
"Most real-world problems aren't solved by caching alone. Unnecessarily raising complexity from the start in a system design interview is actually a minus. What matters is naturally explaining only the necessary parts in depth, layer by layer, according to the problem's scale."
"In reality, a single Postgres instance is sufficient for most use cases, yet even at startups, you have to say you'd use 'Kafka or a distributed queue' to get a passing score — a tragicomic reality."
"As team size grows, over-engineering actually increases. There's a strong desire to pad resumes with new architectures."
It's also pointed out that this interview culture itself is a signal of company culture.
"Companies that demand grandiose answers at a scale that doesn't match the actual problem tend to have that same level of complexity in their actual work. It's worth considering whether you'd actually want to work at such an organization."
4. The "Simplicity" of System Design and Technical Trade-offs
Counterarguments also emerge that complexity isn't always bad design and simplicity isn't always the answer.
"Good design isn't about masking complexity through trade-offs, but the ability to accurately understand the problem's nature and requirements, then determine the right level of complexity and structure."
"In certain situations, complexity is necessary (specific concurrency, scale, horizontal scaling, etc.), so you need to explain the problem's context and logically articulate why simplicity is sufficient or why additional structure is needed."
In practice, most debates about databases, ORMs, and application architecture are connected to these trade-offs.
"In real work, you have to coordinate SQL JOINs, ORM usage, microservice separation, and shared database decisions across diverse situations involving performance, scaling, maintenance, and data issues."
"The moment multiple services directly access a single database, complexity around table schema changes, permission issues, and update conflicts grows exponentially."
5. Interview Tips and Practical Advice
Examples of answers that make a good impression in interviews also appear.
"At the current traffic (QPS), backpressure isn't really an issue, but if traffic grows to Y, we'd need to add a structure like B (e.g., queues/circuit breakers). If growth potential exists or sudden event-driven traffic spikes are expected, I'd design in advance to accommodate that."
"Choosing between SQL and NoSQL shouldn't be about familiarity alone — it should include trade-off explanations covering index structures, join usage, schema migration, data consistency/history management, and more."
The aesthetics of simplicity (Keep It Simple, Stupid) are repeatedly emphasized.
"Start with the simplest approach. For example, a single server + Postgres is sufficient early on, but it's good to mention 'plans only' for how things could evolve as scale grows."
"Specifically mentioning when all trade-offs (simple vertical scaling, caching, the tipping point for transitioning to a distributed architecture, etc.) will become necessary and how you'd detect them can boost credibility." 👍
6. Discussion on Databases, ORMs, and System Architecture
In-depth discussion continues on SQL vs NoSQL, ORM usage, and database design.
- Differing views on ORM usage:
"ORMs are very useful for basic CRUD (Create, Read, Update, Delete), but raw SQL is better for complex queries and performance optimization. However, obsessively sticking to ORM patterns often leads to N+1 problems and other performance issues, so be careful."
- Multi-service database access issues:
"Having multiple services write directly to a single DB/table creates numerous downstream problems around data schema management, permissions, and scaling, so ideally one service/one team should own writes, and everything else should be separated via APIs or events."
- Disagreements on schema design:
"When possible, clear schemas and normalization are recommended; if you overuse flexible approaches (jsonB, key-value structures, etc.), complexity can explode at the application layer."
7. Engineering Culture, Interview Systems, and Organizational Reality
There are also more than a few cynical reactions pointing out that the interview system itself at many IT companies treats complexity as a virtue, and that this is connected to actual workplace culture.
"Rather than writing on LinkedIn that you built a single-line Postgres monolith, listing dozens of microservices and all sorts of fancy stacks on your resume is more welcomed in reality."
"Ultimately, the reality is that developer hiring processes focus more on interview 'answer games' than on the abilities actually needed in practice (problem definition, trade-off judgment, preserving design simplicity, etc.)."
8. Organizational Scale, Change, and Over-engineering
As organizations grow larger, unnecessary complexity (over-engineering) becomes normalized and even required to maintain, the discussion points out.
"The more money a company makes, the more easily over-engineering is tolerated. In return, these are places that shoulder and maintain that enormous complexity while creating value."
9. The Essence of Successful System Design
Finally, many engineers agree on the conclusion that truly good system design "doesn't stand out" and is "too simple to be recognized." 🌱
"In reality, excellent system design shouldn't be about self-congratulation or showy complexity — it should be so simple and logical that anyone can immediately understand it."
"When you look back at our codebase later and find parts that have been running smoothly for a long time without anyone paying special attention — that's where good system design has taken root."
In Closing
Through this discussion, we can reaffirm that "minimal structure + best explanation + logical trade-off awareness" is what truly constitutes good system design. Rather than showing off complexity, many experienced professionals unanimously emphasize the importance of understanding the essence of the problem, logically explaining it with "why?" reasoning, and maintaining a flexible attitude toward handling real change and scalability.
"Complex systems are often not evidence of 'good' design, but rather the accumulated result of 'bad' decisions."
Keeping this in mind, the virtue of simplicity, sound reasoning, and design that can adapt to change may well be the true path of an engineer. 🚀