In March 2023, the Prime Video engineering team published a post that spread quickly through software circles. They rebuilt a video-quality monitoring system from a distributed serverless design into a simpler single-process service. Infrastructure costs dropped by 90%.
Many people read the post as "monoliths beat microservices."
The better lesson is that the team removed unnecessary translation. The old system split one piece of work across too many components. The new system kept the work together.
That pattern appears everywhere. Systems get slow not only because queries are bad or servers are small. They get slow because the same business concept is represented several ways, and the software spends its life translating between them.
The common performance playbook
When a system gets slow, teams usually:
- add a cache
- add an index
- split services
- add a queue
- add a read model
- add a replica
- add a platform layer
These can all help. They can also hide the real problem.
If "customer" means one thing in billing, another in CRM, another in identity, and another in marketing, the system will keep paying a translation cost. If "active subscriber" is computed differently in checkout, support, email, and finance, every workflow has to reconcile the disagreement.
The fastest system is often the one that asks fewer questions because the business concept has one clear home.
The deeper cost of translation
Translation cost is easy to hide because it often looks like normal engineering work.
A team adds a sync job to keep two systems aligned. Then it adds a repair script for the sync job. Then it adds a dashboard to compare the two systems. Then it adds a cache because the comparison is slow. Then it adds an alert because the cache can be stale. Each step is reasonable. The total system is harder to understand than the original business concept.
This is not only a backend problem. It shows up in product operations every day. A customer means one thing in support and another in billing. A campaign means one thing in Meta, another in an email tool, and another in an internal project plan. A refund means one thing to support, another to finance, and another to the growth team measuring margin. The software keeps translating because the business never chose which meaning should be used for the work.
The result is performance drag, but also decision drag. Slow systems are frustrating. Systems with too many meanings are worse: they make teams argue about reality.
The hidden taxes
Too many meanings create four recurring costs.
Reconciliation cost. Services that hold the same concept drift. Teams add sync jobs, repair scripts, comparison dashboards, and manual checks.
Cache cost. A cache is another copy of a value. If the source concept is unclear, invalidation becomes fragile.
Bug cost. A customer can be active in one system and inactive in another. They get charged, locked out, emailed, or refunded incorrectly.
Team cost. New engineers spend weeks learning which version of the concept is "real." Product teams avoid changes because they do not know what will break.
The software cost is only part of the bill. The human cost is usually larger.
Examples
Prime Video reduced cost by making one workflow one workflow again.
Shopify's monolith work is another useful example. The team did not blindly split into microservices. It reorganized a large Rails codebase around business domains like orders, billing, shipping, and inventory. The point was not a fashionable architecture. The point was that important concepts should be understandable and owned.
Segment moved in the opposite direction and reached the same conclusion. It split integrations into many services, then later consolidated them because "deliver an event to a destination" was one concept with variations, not dozens of different services.
The pattern is not "use a monolith." It is "represent the business clearly."
What good architecture protects
Good architecture protects the important business nouns.
Customer. Order. Subscription. Campaign. Offer. Experiment. Approval. Refund. Metric. Decision. These nouns should have clear ownership, clear meaning, and clear rules for change. The implementation can still use services, queues, caches, and read models. The point is that the business concept should not fracture every time the software boundary changes.
This is why simple systems can outperform more fashionable systems. A clean model of the work gives engineers fewer translations, gives operators fewer reconciliation tasks, and gives AI fewer ambiguous objects to reason about. The structure of the business becomes easier to query because the business itself is represented more clearly.
What this means for product systems
Growth software often has this problem.
An offer can live in a doc, a landing page, Shopify, a spreadsheet, an email, and an ad campaign. A campaign can mean an ad campaign, email campaign, launch campaign, or internal project. A customer can mean a visitor, buyer, subscriber, support contact, or Stripe customer.
If those meanings are not tied together, the product will keep adding views, syncs, dashboards, and AI summaries to explain the mess. The system may feel more powerful while becoming harder to trust.
What Lyberty does
Lyberty tries to reduce duplicated business meaning.
The same customer, order, campaign, experiment, approval, document, metric, and decision should not have to be rebuilt separately in every surface. A marketer and finance operator may view the work differently, but they should not be arguing over which object is real.
This is why Lyberty connects offers, pages, ads, emails, spend, orders, experiments, approvals, and decisions around the work itself. It reduces the number of places the company has to translate before it can act.
What to do in your own system
- Pick one core concept: customer, order, subscription, campaign, offer, experiment, or approval.
- List every place it exists.
- Compare the fields and rules in each place.
- Decide which version should be the official operational version.
- Move consumers to that version, then delete the others.
This work does not look glamorous. It removes categories of bugs, reporting fights, and slow workflows.
Sources
- Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%. Prime Video Tech Blog, March 22, 2023. https://www.primevideotech.com/video-streaming/scaling-up-the-prime-video-audio-video-monitoring-service-and-reducing-costs-by-90
- Deconstructing the Monolith. Shopify Engineering, February 21, 2019. https://shopify.engineering/deconstructing-monolith-designing-software-maximizes-developer-productivity
- Goodbye Microservices. Segment Engineering, July 10, 2018. https://www.twilio.com/en-us/blog/developers/best-practices/goodbye-microservices
- The Wrong Abstraction. Sandi Metz, January 20, 2016. https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction
- A Philosophy of Software Design, 2nd Edition. John Ousterhout, 2021. https://www.amazon.com/Philosophy-Software-Design-2nd/dp/173210221X
- How Figma's multiplayer technology works. Figma, October 11, 2019. https://www.figma.com/blog/how-figmas-multiplayer-technology-works/
- Accelerate State of DevOps Report 2024. DORA / Google Cloud, October 2024. https://dora.dev/research/2024/dora-report/
- 2024 Stack Overflow Developer Survey. Stack Overflow, August 2024. https://survey.stackoverflow.co/2024/professional-developers