Sieve Architecture, or the Endless 'Fear Tax'
Let's talk about the elephant in the room. About security, your nerves, and the illusion of control. How many times in the last couple of years has your CTO or sysadmin turned pale reading about another critical vulnerability in the core of a monolithic CMS? You dutifully pay the annual license renewal, thinking you're buying security. In reality, you're paying a 'fear tax' — a tribute to an architectural vulnerability laid down two decades ago.
This is not abstract theory. It's the daily reality for hundreds of businesses whose digital infrastructure is built on the 'monolithic combine' principle. To avoid being unsubstantiated — here's an invoice straight from today's incident report on one of our client projects.
The client's site suddenly started lagging. Hardware was fine, traffic was normal. An emergency audit revealed a picture beautiful in its simplicity: a disguised foreign script was sitting in a system file. With every page load, it made a hidden request to a command domain. The script had been living there for a long time in a completely 'dormant' mode. The problem surfaced only when the hackers' command server went down. The script stopped receiving a response, began to fail with a strict internal timeout of 5 seconds — and dragged down the page generation time for the entire site.
Botnets rarely strike the core directly. They exploit zero-day vulnerabilities in cheap modules from the Marketplace. By slipping through a micro-crack, the hacker gains access to the entire server.
How does this code even get onto the production server if the system is updated? This is the fundamental problem with classic monoliths. They are huge combines of millions of lines of legacy code, where frontend, backend, database, and third-party plugins are all stewing in one common pot.
The script mimics a system file. It is not removed during official platform updates. It simply waits for its hour to leak the client database, hang a hidden miner, or, as in our case, become the single point of failure for the entire system. Updating the core in such a paradigm is running in circles: you patch one hole while the attacker looks for another in one of the dozens of installed modules.
But there is another level of this masochism — financial. We have a pool of projects under support where the frontend hasn't changed for years. The client is satisfied, conversion is happening, new functionality is objectively not needed. Logically, such a site should just work and make money, without requiring investment.
You are not paying for the development of your product, you are paying so that your legs don't get broken.
But instead, the business is forced to dutifully pay money for the vendor's license renewal every year. Why? Solely for security patches. So that this circus just somehow keeps working and isn't turned into a sieve by new threats. This is classic digital racketeering.
See the list of new useful features? Right, there aren't any, only patching old holes.
At the same time, many monolithic CMSs haven't released real product updates for 5-10 years. Zero new features for your business. Their entire changelog is an endless patching of old holes in an architecture conceived in the early 2000s. You're supporting a staff of developers and paying the vendor not to make your site faster or more convenient for customers. You're paying them to endlessly bail water out of a sinking boat.
There is a way out. It lies not in choosing a 'more secure' monolith, but in changing the paradigm itself. A modern stack, such as Astro + PayloadCMS, solves the problem fundamentally. We're not putting new locks on a rotten door, we're removing the door itself.
In Headless architecture, frontend and backend are physically and logically separated, which fundamentally changes the security and ownership cost model.
The frontend, built with Astro, serves the user static HTML, CSS, and JavaScript. Hacking static HTML is like trying to hack a sheet of paper printed on a printer. The server serving the site simply has no executable PHP, Node.js, or other server-side code. There's nowhere to insert hidden curl requests, SQL injections, or malicious scripts.
Your database and PayloadCMS admin panel are not 'exposing their bare backside' to the internet via standard vulnerable paths like `/admin` or `/wp-login.php`, where thousands of brute-force bots knock daily. The backend is hidden in an isolated circuit (private network, VPC) and communicates with the world only via a strictly secured API, sending and receiving dry JSON. The attack surface shrinks by orders of magnitude.
Transitioning to a modern stack is an opportunity to permanently exit the humiliating carousel of 'updated — broke — fixing'. Build the site, export the static files — that's it.
Roadmap for Exiting the Sieve Architecture
Audit and Decomposition
Extract the pure frontend (templates, styles, client-side JS) and data (content structure, products, users).
Determine which dynamic functions are truly necessary (cart, personal account, search) and which can be staticized.
Designing Headless Architecture
For the frontend, choose a static generator (Astro, Next.js in static export mode).
For the backend, choose a CMS with GraphQL/REST API (PayloadCMS, Strapi, Directus).
Plan the data model in the backend and API endpoints for dynamic functions.
Data Migration and Development
Develop the new frontend, which will request data via API at build time (for static content) and on the client (for dynamics).
Set up a CI/CD pipeline for automatic frontend rebuilds upon content updates.
Launch and Decommissioning
Test performance and functionality.
After successful testing, switch DNS to the new infrastructure.
Decommission the old monolithic server.
Abandon annual licenses.
The final architecture can sit on a server for years, not requiring a penny for 'core' updates, because there's nothing to update in terms of frontend security. You pay for the architecture once, get a bulletproof system, and redirect the freed-up budget to marketing or product development, while your competitors are restoring backups after the next hack.
The question is not 'won't Headless be hacked either'. The question is the ratio of the attacker's effort to the potential gain. Hacking an isolated API protected by modern practices and subsequent exploitation through a static frontend is an order of magnitude more difficult than finding a vulnerability in a public WordPress plugin. You make an attack on your business economically unviable.
It's time to stop funding an outdated paradigm. It's time to stop paying the 'fear tax'. Invest in an architecture that works for you, not against you.
Questions and Answers
What about dynamic functionality, like a shopping cart or product search? Static can't do that.
Modern static generators, such as Astro or Next.js, support hybrid rendering. Main content (catalog, articles, pages) is rendered statically at build time. Dynamic parts (cart, search, filters) are implemented as islands of interactivity (Astro Islands) or separate client-side applications that request data from a secured backend API. This provides both the speed of static and the flexibility of dynamic.
Migration from a monolith sounds expensive and risky. Is there a phased approach?
The Strangler Fig strategy. You can start by moving the most problematic or static section (e.g., blog or landing pages) to a Headless stack, leaving complex dynamics (personal account) in the monolith for now. By gradually building up the new architecture and transferring functionality, you reduce risks and distribute the budget. In a year or two, the monolith will be 'strangled' by the new system without a single Big Bang release.
Won't splitting the stack complicate the workflow for content managers?
On the contrary, quality Headless CMSs, such as PayloadCMS, offer a cleaner, more focused, and user-friendly interface for editors than the overloaded admin panels of monoliths. The editor works only with content. After saving, an automatic frontend rebuild is triggered. For the team, it looks like working in a familiar CMS with a slight delay (1-2 min) before publication. But the risks of 'breaking the site' by clicking the wrong button in the admin panel disappear.
Vladislav Baranenkov
CEO BUSTLERSEngineering marketer, replacing routine with algorithms