Scale the current design vs re-architect

The decision

Your system works, and load is growing. You can scale the current design: remove waste, add caches, buy a bigger machine, add copies for reads. Or you can re-architect: change the design itself, for example split the data across servers or break up a service. Scaling the current design is cheap and quick, and it reaches a ceiling. Re-architecture removes the ceiling, but costs months of engineers and brings risk. The forces are how fast load grows, how much runway you have, the money, and the risk of a long change. The usual answer is both: scale now, and start the new design early enough.

Choose to scale the current design when

• Load grows slowly, for example 3% a month, so the runway is long.
• Cheap fixes are still unused: missing indexes, no cache, chatty calls, no batching.
• The team is small or busy with customer work, and cannot carry a long project.
• You do not yet know where the real limit is. A re-architecture built on a guess may fail.

Choose to re-architect when

• Runway after the cheap fixes is shorter than about 1.5 times the time to build the new design (see the numbers).
• A hard ceiling is near, such as a single database that cannot take more writes on any machine.
• Growth is fast, for example 10% a month, so a bigger machine only buys a few months.
• The cost of the bigger machine passes the cost of the new design within a year.
• The current design blocks the product, for example it cannot serve a new region.

The numbers that change the answer

All numbers are assumptions unless marked. Today the busiest database server runs at 60% CPU at peak. You want to stay below 85% at peak, to keep room for spikes. Load grows 10% a month. The new design takes 9 months with 6 engineers at Rs 3,000,000 a year each.

Runway (calculation). Months until the limit = ln(85 / 60) / ln(1.10). Here ln is the natural logarithm. ln(1.4167) = 0.348 and ln(1.10) = 0.0953, so 0.348 / 0.0953 = 3.65 months.

What the cheap fixes buy. Assumption: indexes, caching and batching cut the load by 30%, so peak CPU falls from 60% to 42%. Runway = ln(85 / 42) / ln(1.10) = 7.4 months.

What a bigger machine buys. Assumption: a machine with twice the capacity, so peak CPU falls to 21%. Runway = ln(85 / 21) / ln(1.10) = 14.7 months. It adds ln(2) / ln(1.10) = 7.27 months. Doubling capacity buys 7.27 months at 10% growth, and 23.4 months at 3% growth, if CPU is the only limit. Assumption: the machine costs 2.5 times as much (price rises faster than size at the top). On a Rs 400,000 monthly bill the extra is 1,000,000 - 400,000 = Rs 600,000 a month, or Rs 7,200,000 a year. The 7.27 months of bridge cost about 7.27 x 600,000 = Rs 4.36 million, about Rs 4.4 million.

The cost of the new design (calculation). 6 engineers x Rs 3,000,000 x 9 / 12 = Rs 13.5 million.

The rule (our assumption, not a standard). Start the re-architecture when the runway after the cheap fixes is no more than 1.5 times the build time. That is 1.5 x 9 = 13.5 months. The extra half protects against delay. With the bridge machine the runway is 14.7 months, which is 14.7 - 9 = 5.7 months more than the build time.

The growth rate matters most. At 10% a month, load grows 1.10 to the power of 12 = 3.14 times in a year. At 3% it grows 1.03 to the power of 12 = 1.43 times.

Cited example (Figma). In a blog post of 14 March 2024, Figma wrote that its database stack had grown almost 100 times since 2020. In 2020 it ran a single Postgres database on the largest physical AWS instance. By the end of 2022 it had caching, read replicas and a dozen vertically partitioned databases (groups of related tables moved into their own databases). Figma calls vertical partitioning an easy lever that bought significant runway quickly. In late 2022 it set out to build horizontal sharding. It chose to do that on Postgres, in-house, instead of moving to another database. It gave two reasons: a switch would need a complex data migration across two stores, and it had built up Postgres expertise. It said that, with its fast growth, it had only months of runway remaining (see Sources). This is one company's story, not a rule.

What breaks with each choice

Scale the current design.

• You hit a hard ceiling with no time left. Fallback: measure runway every month and keep a written start date for the new design.
• The cost rises faster than the capacity (2.5 times the price for 2 times the size in the example). Fallback: compare each upgrade with the cost of the new design.

Re-architect.

• It takes longer than planned. With the rule of 1.5 times the build time, a 50% delay still fits.
• Two systems run together during the move, and data must be kept equal. Fallback: move one part at a time, and compare old and new answers before switching.
• The new design is built for the wrong limit. Fallback: load test the old system first and find which resource runs out.

What it costs

• Money: Rs 13.5 million for the new design, against Rs 7.2 million a year for the bigger machine. The new design pays back if growth continues for more than 13.5 / 7.2 = 1.9 years, ignoring its own running costs.
• Reversible-first path. First measure: find the resource that runs out first. Then do the cheap fixes, which cost days and keep every option open. Add read copies or a bigger machine as a bridge. Start the new design when the runway after these steps falls to 13.5 months. Use a small team and a plan to move one part at a time. Keep the bridge until the new design takes the first traffic.
• Changing your mind: scaling up is easy to undo, but you may be stuck with a larger bill. Re-architecture is hard to undo after the data has moved, so move in steps and keep the old path for a few weeks.

How each level answers

The question is: "Your database is at 60% CPU and load grows every month. What do you do?"

SDE-1: I would add an index or a cache, or move to a bigger server. If that is not enough, I would split the data.

SDE-2: First I find the slow queries and fix them. Then I add read copies and a cache. I shard only when the write load cannot fit on one machine.

Senior: With a limit of 85% and growth of 10% a month, I have 3.65 months. Cheap fixes give 7.4 months, and a double-size machine gives 14.7, at Rs 600,000 more a month. The new design takes 9 months, so I start when runway reaches 13.5 months, which has already happened. The fallback is the bridge machine.

Staff: I convert the choice into runway and money: the new design costs Rs 13.5 million, and the bridge costs Rs 7.2 million a year. I agree with product on the growth plan, because it is the main input. I ask a small team to own the new design and the migration, and I stop it if growth slows. I measure peak CPU, runway in months and the cost of each bridge step. I revisit it every month, and whenever growth changes by more than 2 percentage points (Assumption).

Say it in the interview

I would find the resource that runs out first and compute the runway. At 60% CPU, a limit of 85% and 10% monthly growth, that is 3.65 months. Cheap fixes give 7.4, a double-size machine gives 14.7, and a 9-month re-architecture needs a start 13.5 months ahead. So I would bridge with fixes and a bigger machine while a small team builds the new design.

Common mistakes

• Re-architecting before the cheap fixes. An index or a cache may remove 30% of the load in days.
• Ignoring growth. The same system needs action now at 10% growth and in 10 months at 3%.
• Buying a bigger machine as the plan. It buys months, not a design.

Sources

• Figma, "How Figma's databases team lived to tell the scale" (14 March 2024): the database stack grew almost 100 times since 2020; in 2020 it ran a single Postgres database on AWS's largest physical instance; by the end of 2022 it had caching, read replicas and a dozen vertically partitioned databases; vertical partitioning bought significant runway quickly; it started horizontal sharding in late 2022; switching to other databases would need a complex data migration across two stores; it had expertise running RDS Postgres in-house; with its aggressive growth it had only months of runway remaining. https://www.figma.com/blog/how-figmas-databases-team-lived-to-tell-the-scale/ (opens in a new tab) (checked 26 Oct 2026)
• The CPU levels, the 85% limit, growth rates, the 30% cut from cheap fixes, machine prices, team size, build time, the 1.5 factor and the 2-point trigger are our assumptions. The runways, costs and break-even years are our calculations, shown above. The Figma facts are cited.