Archive Review

Magento Review

The purpose of this and future reviews are to take a look inside software to see how they were built and ultimately try to learn something. It’s much easier to look at open source code and I also used to be a Magento Developer so my first review will be about Magento.

Magento 1 is a very large codebase with over 4 and half million lines of code. You’ve probably used Magento if you’ve ever done online shopping since it was and still is the most popular e-commerce platform for medium to large sized retailers. Because of it’s a problem how decide what to review. Probably the best way to go about this is to review only what makes Magento unique and parts that we can learn the most out of.

Magento is a lot like most modern web frameworks, it has a URL routing system, MVC, ORM etc. To find what makes it unique we have to see what unique problems it was trying to solve.


MySQL had a row limit of 65535 bytes. This was an issue if you wanted a platform where retailers didn’t have to worry about how many product attributes they were adding to the system. Imagine if you have a product object with over hundreds of product attributes, each attribute would be a column. That wouldn’t be possible because you would hit the row limit for MySQL.

Magento’s solution to this problem was using something called Entity-Attribute-Value (EAV). Essentially the idea was to take columns and turn them into rows.

You would have three tables: the object table, the object attribute table and the table for the values of those attributes.

For example: you would have a product with a product_id:123. In the “Attribute” table it would basically reference that product_id.

123 | some_attribute_name | value_id

Then finally to find what the value of your attribute you would look up the value table

value_id | "This product is red"


Magento 1 was started around 2008 with the first open source contributions in 2011. Back then most websites used MySQL and the hardware running them weren’t very fast either.

A 2011 white paper describing what Magento usually ran on

Now how Magento solved this issue was to use large amounts of caching. Anything you can think of was cached to make the websites load faster.

Block Caching

Magento structured it’s front end system for this problem. Essentially there were blocks of a page that you would structure in a XML file and that would be cached.

OPCode Caching

PHP today still does not have JIT compilation but the most recent versions is much faster then what it was in 2011. Another optimization that wasn’t specific to Magento but was used in every instance was to cache the bytecode for PHP so that it doesn’t have to recompile on every request.

Flat Tables

Although this isn’t a cache it acted like one on the database side. The EAV system we talked about earlier is great for flexibility. The problem is what used to be all on one table is now on at least 3 tables requiring more joins and slowing down each request.

Flat tables basically brought every attribute and value back into one table (if it could) and that temporary table would be used as a sort of “cached view” of the EAV.