This article is a real-life case study of modernizing a legacy PHP application with the Strangler Pattern - migrating a product catalogue from Zend Framework to Symfony, syncing data between the two systems, and the lessons learned from years in production.
\nTL;DR
\nTIMESTAMP column and one guarded DELETE.When implementing a Strangler Pattern approach, one of the key things to master is to keep the new data model clean. More often than not, the model is transferred, or the new model is heavily influenced by the legacy one. As a result, the new system has a newer framework, slightly better codebase, but the deep modelling issues remain, and they make development slow and hard.
\nA few weeks ago I published a practical guide to the Strangler Pattern. In it I made a claim that deserves proof: when you split the database during a migration, the synchronization between the old and the new store does not have to be sophisticated. More often than you would expect, a delay is perfectly acceptable, and that makes your life much easier.
\nThis is a case study from one of our long-running projects: a marketplace platform where a legacy Zend Framework application and a new Symfony application ran side by side for years.
\nThe platform lets shop owners design custom apparel and sell it in their own storefronts. The legacy side is a classic Zend Framework 1 application - thousands of files, models mixed with raw SQL, an admin panel, background jobs, the works. The new side was planned as a Symfony application with a properly modeled domain: bounded contexts for products, shops and currencies, repositories, value objects.
\nFor a migration to succeed, it needs to deliver value to the business. No business owner will be happy to pay for months or years of work without a positive return on investment (ROI). A good place to start needs to combine a positive ROI, low risk, and being rather easy to work on if you are new to the project (and we were).
\nAfter some research, many discussions with the business owners, and a code review, we have chosen to start with a product catalogue page. Some reasons why this was a good candidate:
\nThe important constraint: the legacy application remains the system of record for products. Shop owners still create and edit products through the legacy admin. The new application only renders the catalog and the product pages (as a second step), from its own database, with its own clean model. That single decision - one writer, one reader - is what allows the sync to stay simple. Data flows in exactly one direction, and there is no risk of corrupted data. Legacy is always the source of truth (at least at this stage).
\nThe second decision that keeps things simple: eventual consistency is fine here. If a shop owner renames a product and the public catalog shows the old name for three more minutes, nobody notices and nothing breaks. No money is moving. The moment you accept that, you can throw away most of the complicated options.
\nSo we introduced a new Symfony application that ran next to the old one. The HTTP(S) routing was very simple, and we kicked it off with just a couple of Apache config rules (Apache was already running):
\n# New app takes the product pages...\nProxyPass /p http://new/p\n# ...and the catalogue\nProxyPass /c http://new/c\n\n# Everything else stays on legacy\nProxyPass / http://legacy/With that in place, the new application needed the legacy product data - and after considering different approaches, the whole synchronization mechanism came down to three pieces:
\nNo Kafka, no Debezium, no message broker. And it ran in production, reliably, for years.
\nI will walk through the whole pipeline end to end, including the anti-corruption layer that kept the legacy schema out of the new domain model. And because we wrote this code quite a while ago, we know how it aged: it ran for years with very little maintenance.
\nThe first problem: how do you know a product changed? The textbook answer is to publish an event from the application whenever a product is saved. The textbook answer assumes your application has one place where products get saved.
\nOurs had many. Products were written by the shop owner panel, by the admin panel, by CSV importers, by background jobs, and by a couple of raw SQL statements scattered where you would least expect them. Finding and instrumenting every write path in a legacy codebase is exactly the kind of archaeology the Strangler Pattern is supposed to spare you. It is just risky, and the chances you will miss one are too high.
\nSo we went one level below the application, where all those write paths converge anyway: the database. A queue table and a set of triggers:
\nCREATE TABLE `shop_item_updated` (\n `shop_item_id` bigint(20) unsigned NOT NULL,\n `updated_at` TIMESTAMP NOT NULL,\n PRIMARY KEY (`shop_item_id`)\n);\n\nCREATE TRIGGER after_shop_item_updates\n AFTER UPDATE ON shop_item\n FOR EACH ROW\nBEGIN\n INSERT INTO shop_item_updated (shop_item_id, updated_at)\n VALUES (OLD.id, NOW())\n ON DUPLICATE KEY UPDATE updated_at = NOW();\nEND;\n\nCREATE TRIGGER after_shop_item_updates_insert\n AFTER INSERT ON shop_item\n FOR EACH ROW\nBEGIN\n INSERT INTO shop_item_updated (shop_item_id, updated_at)\n VALUES (NEW.id, NOW());\nEND;Two design details here matter more than they look.
\nThe queue stores dirty flags, not events. There is no payload, no \"what changed\", no event type. Just \"product 4711 changed at 14:32\". That has a lovely consequence: the primary key on shop_item_id plus ON DUPLICATE KEY UPDATE means the queue naturally coalesces. A product edited fifteen times between two sync runs occupies one row and gets synced once. The queue physically cannot grow beyond the number of products. You get deduplication for free, from a primary key.
If you know the theory: this is a poor man's transactional outbox crossed with change data capture. The trigger runs in the same transaction as the write, so a change and its queue entry are atomic - you cannot lose a change the way you can with \"save, then publish to a broker\". Tools like Debezium give you the same guarantee by tailing the binlog, with ordering and payloads on top. We did not need ordering or payloads, so we did not pay for them. And the price of such tools is easy to underestimate: adding Debezium is a day of work, but from that day on you are running and monitoring Kafka Connect, upgrading it, and fixing it when a connector silently stops. With the trigger approach, there was simply nothing extra to operate.
\nA product page is not built from one table, though. It also depends on related tables like translations, so those got triggers too - each one resolving back to the affected product IDs:
\nCREATE TRIGGER after_shop_item_language_updates\n AFTER UPDATE ON shop_item_language\n FOR EACH ROW\nBEGIN\n INSERT INTO shop_item_updated (shop_item_id, updated_at)\n VALUES (OLD.shop_item_id, NOW())\n ON DUPLICATE KEY UPDATE updated_at = NOW();\nEND;And the same pattern was repeated for the other synced entities like shops - one queue table per aggregate.
\nThe mechanism evolved through production bugs, which I think is worth admitting. Products on this platform have child variants, and the first version of the trigger only enqueued the row that changed. Result: edit a parent product, and its variants quietly kept serving stale data. The fix was a follow-up migration that widened the trigger:
\nCREATE TRIGGER `after_shop_item_updates`\n AFTER UPDATE ON `shop_item`\n FOR EACH ROW\nBEGIN\n INSERT INTO shop_item_updated\n SELECT id, NOW() FROM shop_item\n WHERE id = OLD.id OR parent_id = OLD.id\n ON DUPLICATE KEY UPDATE updated_at = NOW();\nENDThis is the trade you make with triggers: the logic of \"what does this change affect\" lives in SQL, in the database, where nobody is looking. Trigger logic does not show up in the PHP codebase, code search does not find it, and new developers do not know it exists. If you go this route, treat triggers as first-class code: keep them in versioned migration files, mention them in the developer docs, and keep them dumb - flag an ID, nothing more. Thankfully, we caught the issue very fast, and the fix was easy.
\nThe new application could have just connected to the legacy database and read the queue table directly. We deliberately did not do that. Instead, the legacy application exposes an internal HTTP API, and this is where the anti-corruption layer starts - on the legacy side.
\nThe endpoint joins the queue table against the product data and returns a batch, oldest changes first:
\n// Legacy (Zend) - the internal sync endpoint, trimmed\npublic function listproductsAction()\n{\n $this->checkIp();\n\n $shopItemModel = new Default_Model_ShopItem();\n $shopItems = $shopItemModel->getForSyncWithJoins($this->getParam('limit'));\n\n $productMapper = new ProductMapper($this->view);\n $mapped = [];\n\n // $images, $children and $categoryMapper are prepared\n // for the whole batch - trimmed for brevity\n foreach ($shopItems as $row) {\n $shopItem = ShopItemFactory::create($row, $images);\n $product = $productMapper->mapToProduct($row, $shopItem, $children);\n $product['category'] = $categoryMapper->mapToTypeAndAssortment(\n $shopItem->getPatternCategoryId()\n );\n\n $mapped[] = $product;\n }\n\n $this->getResponse()\n ->setBody(json_encode($mapped))\n ->setHttpResponseCode(200);\n}The interesting part is what ProductMapper does. It does not dump the legacy row. It builds a deliberate contract - clean names, resolved relations, computed flags:
// Legacy - mapping internal mess into a published contract\npublic function mapToProduct(array $row, Default_Entity_ShopItem $shopItem, ...)\n{\n return [\n 'id' => $shopItem->getId(),\n 'name' => $shopItem->getName(),\n 'price' => $shopItem->getPrice(),\n 'description' => html_entity_decode($shopItem->getDescription()),\n 'updated_at' => $row['updated_at'],\n 'shop' => [\n 'subdomain' => $shopItem->getSubdomain(),\n 'externalUri' => $shopItem->getExternalDomain(),\n 'id' => $shopItem->getShopId(),\n ],\n // three legacy flags collapse into one meaningful boolean\n 'deleted' => $row['is_deleted']\n || $row['parent_is_deleted']\n || $row['pattern_is_deleted'],\n 'enabled' => !$shopItem->isDisabled() && !$row['pattern_is_hidden'],\n // ...\n ];\n}Look at that deleted line. In the legacy schema, \"is this product gone\" is a question you can only answer by checking three flags across three tables - the product, its parent, and its pattern. The mapper answers the question once, at the boundary, and the new system never learns the question existed. That is anti-corruption in one line of code.
In DDD terms this endpoint is an open host service speaking a published language: the legacy context translates its internal chaos into an agreed contract before anything crosses the boundary. It also means the legacy team can refactor their tables without breaking the new app, as long as the JSON stays the same. We got to use that freedom more than once.
\nOne comment worth mentioning here: the three different delete flags might make sense in some cases, but not in ours. We were rebuilding a product catalogue, and for a catalogue it does not matter why a product got deleted. We only care whether it is deleted. If you know you will need those distinctions later, you might want to expose the flags separately and implement that part of the ACL in the new system.
\nOn the Symfony side, a single console command runs from cron:
\n# ansible crontab role\n- name: sync\n minute: \"*/3\"\n job: \"php bin/console -eprod app:sync -v >> cron.log 2>&1\"Every three minutes. That number was not scientific - it was \"fast enough that no shop owner ever complained, slow enough that the batches stay small\". We never had to change it.
\nThe command itself is mostly plumbing: a lock so runs cannot overlap, and a list of sync providers:
\nclass SyncCommand extends Command\n{\n use LockableTrait;\n\n const TYPES = ['shop', 'product' /*, ... and more */];\n\n protected function execute(InputInterface $input, OutputInterface $output)\n {\n if (!$this->lock()) {\n $output->writeln('The command is already running in another process.');\n return;\n }\n\n try {\n $this->syncManager->syncAll();\n } catch (\\Exception $e) {\n $this->release();\n throw $e;\n }\n // ...\n $this->release();\n }\n}The LockableTrait is doing quiet but essential work here. Batches sometimes take longer than three minutes - a big CSV import on the legacy side can enqueue thousands of products at once. Without the lock, cron would happily start a second run on top of the first, and you would sync the same products twice, concurrently, into the same tables. One trait, one line, whole class of bugs gone.
Synchronizers register through a Symfony tag with priorities, because order matters - you cannot sync a product into a shop that does not exist yet:
\nApp\\Infrastructure\\Synchronizer\\ShopSynchronizer:\n tags: [{ name: synchronizer, priority: 90 }]\nApp\\Infrastructure\\Synchronizer\\ProductSynchronizer:\n tags: [{ name: synchronizer, priority: 80 }]Shops before products. Dependency ordering as configuration - simple and visible.
\nThe product synchronizer is where the batch is processed. Trimmed to its essence:
\nclass ProductSynchronizer implements Synchronizer\n{\n const LIMIT = 200;\n\n public function sync()\n {\n $timestamp = (new \\DateTime())->getTimestamp();\n $productsData = $this->productApi->findAll(self::LIMIT);\n $synchronized = [];\n\n foreach ($productsData as $product) {\n try {\n $this->synchronizeProduct($product);\n } catch (\\Exception $e) {\n $this->logError(self::LOG_MESSAGE, ['error' => $e->getMessage()]);\n\n continue; // one broken product must not stop the batch\n }\n\n $synchronized[] = $this->productTranslator->getId($product);\n }\n\n $this->em->flush();\n $this->productApi->markAsSynchronized($synchronized, $timestamp);\n }\n}Three things to notice:
\n$synchronized, so its queue row survives and it will be retried on the next run.The confirmation call is the most subtle part of the whole design. The new side reports back which products it managed to process, along with a timestamp:
\npublic function markAsSynchronized(array $ids, int $timestamp)\n{\n $this->client->request('POST', 'synchronizedProducts', [\n 'json' => ['ids' => $ids, 'timestamp' => $timestamp],\n ]);\n}And the legacy side deletes the queue rows - but only if they have not been touched since:
\nDELETE FROM shop_item_updated\nWHERE shop_item_id IN (:ids)\n AND UNIX_TIMESTAMP(updated_at) <= :timestampThat updated_at <= timestamp condition is what makes the mechanism safe. Consider the race: the sync fetches product 4711, and while the batch is being processed, a shop owner edits that same product. The trigger bumps updated_at in the queue. When the confirmation arrives, the timestamp check sees a newer updated_at and refuses to delete the row - so the product is synced again next run, picking up the fresh edit. A naive DELETE WHERE id IN (...) would have silently lost that update.
This gives you at-least-once delivery: a product may be synced twice, but never zero times. At-least-once only works if processing is idempotent, and here it is - the new side upserts by the legacy product number through mapping tables, so syncing the same product twice just overwrites identical data.
\nThe pattern at work here has a name: at-least-once delivery plus idempotent consumer. It is the boring, battle-tested foundation under most reliable messaging systems, and you can implement it with a TIMESTAMP column and a DELETE ... WHERE.
The data that arrives is clean-ish JSON, but it is still the legacy contract - legacy IDs, legacy category names, legacy quirks like 0000-00-00 00:00:00 dates. None of that is allowed anywhere near the new domain model. The new side runs it through three stages.
Stage one: the translator. It absorbs the quirks and maps legacy identifiers onto the new world:
\nclass LegacyProductTranslator implements ProductTranslator\n{\n public function createFromArray(array $data): array\n {\n // legacy pattern_id -> SKU of the base item in the NEW catalog\n $baseItemMap = $this->patternMapRepository\n ->findOneByPatternId($data['pattern_id']);\n\n // has this legacy product been synced before?\n $productMap = $this->productVersionMapRepository\n ->findOneByLegacyId($data['id']);\n\n // a classic MySQL legacy quirk, absorbed here and nowhere else\n if ('0000-00-00 00:00:00' == $data['created_at']) {\n $data['created_at'] = '1970-01-01 00:00:00';\n }\n\n return [\n 'number' => $data['id'],\n 'base_item_sku' => $baseItemMap ? $baseItemMap->getBaseItemSku() : null,\n 'current_product_sku' => $productMap ? $productMap->getProductSku() : null,\n 'name' => $data['name'],\n 'created_at' => new \\DateTimeImmutable($data['created_at']),\n 'enabled' => filter_var($data['enabled'], FILTER_VALIDATE_BOOLEAN),\n 'deleted' => filter_var($data['deleted'], FILTER_VALIDATE_BOOLEAN),\n 'prices' => [\n $shop->getDefaultCurrency()->getIsoCode() => $data['price'],\n ],\n // ...\n ];\n }\n}Those two repository lookups are the heart of the ACL. The old and the new system do not share identifiers - the legacy world thinks in numeric pattern_ids, the new catalog thinks in SKUs. Dedicated mapping tables (BaseItemVersionToPatternMap, ProductVersionToLegacyMap) are the only place where both ID schemes appear together. The domain model itself carries no legacyId column. When legacy dies, you drop the mapping tables and the domain does not notice.
Stage two: a validated event. The translated payload becomes an explicit event with the contract enforced in the constructor:
\nclass ProductDataChangedEvent\n{\n public static function create(array $payload): self\n {\n $self = new self();\n $self->validate($payload); // asserts required fields exist\n $self->payload = $payload;\n\n return $self;\n }\n\n public function getName(): string\n {\n return $this->payload['name'];\n }\n // ... typed getters for every field\n}Stage three: a domain listener that speaks only the new language. This is the first place in the whole pipeline where domain objects are built, and notice what it imports - repositories, value objects, factories from the new bounded context. Not one legacy concept:
\nclass UpdateProductEventListener\n{\n public function __invoke(ProductDataChangedEvent $event)\n {\n $baseItem = $this->baseItemRepository->findOneBySku($event->getBaseItemSku());\n if (!$baseItem) {\n return; // base item not in the new catalog -> not our concern yet\n }\n\n $shop = $this->shopRepository->findOneByIdentifier($event->getShopIdentifier());\n\n $sku = $baseItem->getSku() . '_' . $this->skuGenerator->getSKU() . '_' . $event->getNumber();\n\n $commission = Commission::PERCENTAGE === $event->getCommissionType()\n ? Commission::createPercentage($event->getCommissionValue() / 100)\n : Commission::createFixed([new Price($shop->getDefaultCurrency(), $event->getCommissionValue())]);\n\n $product = new Product(\n $sku, $baseItem, $event->getName(), null, $shop,\n $event->getDescription(), $commission, $event->getCreatedAt()\n );\n\n $event->isDeleted() ? $product->delete() : $product->restore();\n\n $this->productRepository->save($product, true);\n }\n}In my practical guide I gave a simple test for a real ACL: grep your new codebase for the word legacy - every hit outside the ACL is a leak. Running that grep on this project, the hits cluster in Infrastructure/ - LegacyProductApi, LegacyProductTranslator, the mapping entities. The Domain/Model directory comes back clean. Held for years, that line is the difference between a migration and a reshuffle. The word itself is not the point - extend the test to any legacy concept you deliberately dropped from the new model, and you will not find those either.
Was it perfect? No. The translator returns an array instead of a typed object - there is literally a @todo this should maybe return a Product instance? on the interface, and it stayed a todo for years. If I were building it today, that boundary would be a typed DTO validated field by field. But the placement of the boundary was right, and placement is what you cannot fix later.
And that is it - the full sync, end to end. Based on the domain events and models, we were able to build a new, fast and efficient product catalogue, and later easily extend it to product pages with pricing info. Unfortunately, the migration was stopped soon after, for business rather than technical reasons - so this time we never got to click \"delete\" on the legacy part the way we did in other projects. More on that in the closing thoughts.
\n\nStep back and count the moving parts: two queue tables, a dozen triggers, one internal HTTP API, one console command, one cron entry. That is the entire synchronization infrastructure for strangling the product catalog out of a monolith. No broker to operate, no CDC connector to babysit, no schema registry. When sync misbehaved, debugging looked like SELECT * FROM shop_item_updated ORDER BY updated_at LIMIT 20 and reading a cron log.
The simplicity was not luck. It was bought by three constraints we chose early and defended:
\nAnd around the simple pipe, the discipline that actually mattered: a mapper publishing a clean contract on the way out of legacy, and a translator absorbing quirks on the way into the new system, so that after years of syncing, the new domain model still did not know what a pattern_is_hidden flag was.
The sync outlived every estimate we made for it, which is true of most \"temporary\" migration infrastructure - in the guide I called this the \"short-lived forever\" state, and this project is where I learned it. Build the temporary thing simple enough that running it for years does not hurt, and clean enough that deleting it is a DROP TRIGGER and a git rm.
For this project, operational cost. Debezium means running Kafka Connect (or at least a Debezium server), monitoring a binlog reader, and handling connector failures - permanent infrastructure for a temporary migration. The trigger approach needed nothing that was not already there. CDC earns its keep when you need ordered event streams with payloads, multiple consumers, or near-real-time latency. For one consumer that tolerates minutes of delay, a queue table is hard to beat. And it served the traffic we had pretty well.
\nBetter than intuition suggests, because the queue coalesces. The batch size is bounded by \"products changed since the last run\", not by write volume - a product saved fifty times is still one row. Our batches rarely approached the 200 limit outside of bulk imports, and those simply drained over a few consecutive runs. If your change rate outgrows the interval permanently, that is the signal to move to a streaming approach - but measure first.
\nPull keeps the legacy side passive and nearly untouched - the strangler ideal. A push design means the legacy app must know the new system's address, handle its downtime, implement retries and backoff. With pull, all the intelligence lives in the new codebase, where you actually want to write code, and legacy's only job is to answer two HTTP endpoints. If the new side is down, changes accumulate safely in the queue table until it comes back.
\nTriggers holding business logic are a well-earned antipattern - invisible, hard to test, painful to debug. Triggers as a change-tracking mechanism are a different animal: a single dumb statement, no decisions, flagging an ID. That is a pragmatic form of change data capture, and it solved the one problem application-level events cannot solve in a legacy system - catching the write paths you do not know about. Keep them dumb, keep them in versioned migrations, document them where developers will look.
\nDedicated mapping tables, owned by the new system's infrastructure layer. Legacy IDs never appear on domain entities - only in *ToLegacyMap tables that pair a legacy identifier with a new SKU. The domain model references only its own identifiers. When the legacy system is finally decommissioned, the mapping tables are dropped and the domain schema does not change at all - which is a good test of whether your ACL is real.
Does this always work? No, it does not, and it should not be your default approach. Triggers, queue tables and cron jobs are one possible answer, chosen for one specific situation: a single writer, a single reader, and a business that could accept a few minutes of delay. What I wanted to show is that good modelling and an open mind are the key to a simple, easy to maintain solution. When the boundaries are right, the machinery between them can stay boring.
\nThere is one more reason this project stuck with me. As I mentioned, the migration was eventually stopped - a business decision, nothing to do with the technology. And nothing broke. We did not back out of a half-finished rewrite, nobody scrambled to patch a system stuck between two worlds. We simply stopped, with every strangled piece still running in production and the legacy app still handling the rest. In the practical guide I wrote that if you have to pause a strangler migration, you still have a fully working product. This is the project where I saw that safety net catch a real fall.
","timeToRead":19,"frontmatter":{"title":"Clean Model Always Wins: A Strangler Pattern Data Sync Case Study","tags":["php","software-development","code-quality","modernization"],"author":"mkurzeja","categories":["for-developers"],"dateUpdated":null,"customTopics":[["The Strangler Pattern - A Practical Guide","/strangler-pattern-practical-guide","blog"],["Strangler Pattern in practice","/strangler-pattern-in-practice","blog"],["PHP Code Quality with PHPStan","/how-to-ensure-php-code-quality-static-analysis-using-phpstan-with-symfony","blog"],["PHP Modernization","https://accesto.com/services/php-refactoring-services/","services"]],"customCTA":["Need help with PHP refactoring?","https://accesto.com/contact/","Talk to us"],"customContactCTA":["Need help with PHP refactoring?","We work on mature PHP systems — performance, modernization, and architecture.","Talk to us","https://accesto.com/contact/"],"customContactCTAIcon":null,"heroImage":{"childImageSharp":{"fluid":{"base64":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAAKCAIAAAA7N+mxAAAACXBIWXMAAAsTAAALEwEAmpwYAAAB7UlEQVQoz02RzW7TQBSFbY89Y1BS2zPTum4i2iZtE0KaovIjoCCyKGrFhjqNf+Jx0jalJAoVsAhqs2CF2NEdCyRExZLyBogNEg/CmrfgOqaA9OnqXN05upp7JEL9f7CA0ABTH1MPWb5GA8I80Of46QizAFueZjUl8OgMCP7AkwrjKaeRpVtSpkH+2iwPm00wEx5Cq1FPgl6ZaCBjG1CyjVTLWZezjYVSO1/uI6MJNgJOu4VzMbaaOOsSwyWw2crHiyuDwnK/UO0vrQzmKk/mLj/OlXvtw9Pjk2+NwSfqeMTcQhkX2S10aUeF5auvtNlestkpdm/Vj9bWR9fuDq/fG4Kw53dmqi8e7n24uRoM6huVO4cZcYYWnma8z/TZD6V2nPXPLm5+VCpHkpET08XuzOK+Xejahf186WDCEcb8Qe3+qHx17/aVR8vrw8L7X8qDd+rud/z6p1w/kf0vqP1VWXsrwX9UM0Gz4CQhMnxkBoRvTxfbmZyQjFCaHSjuKSo9l0sv5Rtv0FRH5TGqjlBtJBE4NYfXCToPdd7SucA0Uq1QoxGmguR21aWe5nSw4SdQgVmETUg0ksbxjhPmIWEh5JRULnQeERbpLNaZ0K1E4MkO5kCcQrj4z8zCcU1FKyVx8lifjC9ATQznMEFo9Buae3BDGG76PwAAAABJRU5ErkJggg==","aspectRatio":1.9736842105263157,"src":"/blog/static/c7307a4ce77c9f6de8cb9ac9a4b2e93d/f3583/strangler_pattern_data_sync.png","srcSet":"/blog/static/c7307a4ce77c9f6de8cb9ac9a4b2e93d/630fb/strangler_pattern_data_sync.png 300w,\n/blog/static/c7307a4ce77c9f6de8cb9ac9a4b2e93d/2a4de/strangler_pattern_data_sync.png 600w,\n/blog/static/c7307a4ce77c9f6de8cb9ac9a4b2e93d/f3583/strangler_pattern_data_sync.png 1200w,\n/blog/static/c7307a4ce77c9f6de8cb9ac9a4b2e93d/7adbf/strangler_pattern_data_sync.png 1660w","sizes":"(max-width: 1200px) 100vw, 1200px"}},"publicURL":"/blog/static/c7307a4ce77c9f6de8cb9ac9a4b2e93d/strangler_pattern_data_sync.png"}},"fields":{"date":"2026-09-21"}},"authorImage":{"childImageSharp":{"fluid":{"base64":"data:image/jpeg;base64,/9j/2wBDABALDA4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxOQERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVGC8aGi9jQjhCY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2P/wgARCAAUABQDASIAAhEBAxEB/8QAFgABAQEAAAAAAAAAAAAAAAAAAAQF/8QAFgEBAQEAAAAAAAAAAAAAAAAAAgAB/9oADAMBAAIQAxAAAAHakshK0gjHKMUiz//EABoQAAMBAAMAAAAAAAAAAAAAAAECAwARMTL/2gAIAQEAAQUCckBGqtM/mTBq6rnnphRt/8QAFxEBAAMAAAAAAAAAAAAAAAAAEAExQf/aAAgBAwEBPwHCaP/EABYRAQEBAAAAAAAAAAAAAAAAABABMf/aAAgBAgEBPwEmn//EABwQAAEEAwEAAAAAAAAAAAAAAAEAAhAhESIxQf/aAAgBAQAGPwLXqAe4OBgryMKqj//EABsQAQADAAMBAAAAAAAAAAAAAAEAESEQMUFh/9oACAEBAAE/Ic+01vkwePhVcd5LCVcbG48BRwlDpF8lLxn/2gAMAwEAAgADAAAAEJvPAv/EABcRAQEBAQAAAAAAAAAAAAAAAAERABD/2gAIAQMBAT8QAp4msLN//8QAFxEBAQEBAAAAAAAAAAAAAAAAAREAEP/aAAgBAgEBPxBW8BGQu//EABwQAQEAAgIDAAAAAAAAAAAAAAERADEQIVFhcf/aAAgBAQABPxAjFiOnTbiUxdk5b864nqAqeTBq5t2poOECEYpvWIZpWmVm8PK+xM//2Q==","aspectRatio":1,"src":"/blog/static/e68dd4372e7cd1a7a108492da7836f1a/ea649/mkurzeja.jpg","srcSet":"/blog/static/e68dd4372e7cd1a7a108492da7836f1a/b1092/mkurzeja.jpg 11w,\n/blog/static/e68dd4372e7cd1a7a108492da7836f1a/1d7ec/mkurzeja.jpg 21w,\n/blog/static/e68dd4372e7cd1a7a108492da7836f1a/ea649/mkurzeja.jpg 42w,\n/blog/static/e68dd4372e7cd1a7a108492da7836f1a/1c2ab/mkurzeja.jpg 63w,\n/blog/static/e68dd4372e7cd1a7a108492da7836f1a/567fa/mkurzeja.jpg 84w,\n/blog/static/e68dd4372e7cd1a7a108492da7836f1a/79880/mkurzeja.jpg 412w","sizes":"(max-width: 42px) 100vw, 42px"}}}},"pageContext":{"slug":"/clean-model-always-wins-strangler-pattern-case-study/","authorImagePath":"mkurzeja.jpg"}},"staticQueryHashes":["1607616503","473848531"]}