# Avoiding Overengineering: Choose Architecture and Databases for the Job

DevFeed: [Avoiding Overengineering: Choose Architecture and Databases for the Job](<https://devfeed.tech/articles/yagni-cargo-cult-and-overengineering-the-planes-won-t-land-just-because-you-built-a-runway-in-your-backyard-24982.md>)

Original publisher: [Read original article](<https://codeahoy.com/2017/08/19/yagni-cargo-cult-and-overengineering-the-planes-wont-land-just-because-you-built-a-runway-in-your-backyard/>)

Author: umer

Published: 2017-08-19T00:00:00Z

Content type: opinion

Language: en

Sources: [Code Ahoy - Articles](<https://devfeed.tech/sources/code-ahoy-articles.md>)

Topics: [Databases](<https://devfeed.tech/topics/databases.md>), [Architecture & Design](<https://devfeed.tech/topics/architecture-design.md>), [MySQL](<https://devfeed.tech/topics/mysql.md>), [NoSQL](<https://devfeed.tech/topics/nosql.md>), [Microservice](<https://devfeed.tech/topics/microservice.md>), [Apache Cassandra](<https://devfeed.tech/topics/cassandra.md>)

Tags: [architecture](<https://devfeed.tech/tags/architecture.md>), [cassandra](<https://devfeed.tech/tags/cassandra.md>), [databases](<https://devfeed.tech/tags/databases.md>), [microservices-architecture](<https://devfeed.tech/tags/microservices-architecture.md>), [mysql](<https://devfeed.tech/tags/mysql.md>), [nosql](<https://devfeed.tech/tags/nosql.md>)

## AI overview

The author reflects on choosing technologies based on actual needs rather than hype. They describe replacing a monolith and MySQL with service-oriented architecture and Cassandra, concluding that the resulting system was too complex for a small startup team to maintain.

## Source excerpt

It was April. Year was probably was 2010. The cold, snowy winter was finally coming to an end and the spring was almost in the air. I was preparing for my final exams. The review lectures were going on for the RDBMS course that I was enrolled in at my university. Around the same time, I had started hearing and reading about the shiny, new technology that was going to change the way we use databases. The NoSQL movement was gaining momentum. I was reading blogs about how MongoDB is big time outperforming ancient, non web scale relational databases. After the lecture, I asked my professor: Me: So, between RDBMS and NoSQL databases, which one do you think is the best? Professor: Well, it depends. Me: Depends on what? Professor: Depends on what you are trying to achieve. Both have their pros and cons. You pick the right tool for the job. Me: But MySQL can't really scale. Professor: How do you think we got this far? Send me an email and I'll send you some papers and practical uses in the industry. SQL was hard for my brain, especially the joins. I loved NoSQL. Simple key->value model without any joins! RDBMS systems that were designed in 1960's were simply not enough to keep up with modern demands. I had lost all interest in RDBMS and predicted they'll just fade off in the next few years. It's 2012. We're redesigning my employer's flagship product. The first version was a monolith that used the boring MySQL. Spending too much time reading blogs and Hacker News comments section, we convinced ourselves that we need to go big and modern: Break monolith into service-oriented architecture, aka, the SOA. Replace MySQL with Cassandra (MySQL to Redis to Cassandra) And we built it. There was nothing wrong with the new system... except one major flaw. It was too complex for a small startup team to maintain. We had built a Formula One race car, that makes frequent pit-stops and requires very specialized maintenance, when we needed a Toyota Corolla that goes on for years and years on j