Developer Stories: Jaafar on Building Reliable Systems for Arabic Newsrooms
Developer Stories is a CoderLegion series highlighting the real journeys, challenges, lessons, and experiences of developers building software in the real world.
For this edition, we spoke with Jaafar, founder of ManTek Technologies in Dubai, about his journey from studying IT engineering and AI at Damascus University to working with AWS, WordPress, and high-traffic publishing systems.
Rather than focusing on a traditional career timeline, this conversation explores something developers often learn only through experience: the difference between systems that appear to work and systems that can actually be trusted.
From silent failures and Arabic-language challenges to scaling WordPress and building NUZ, Jaafar shares lessons learned from working with production systems where mistakes can become visible to thousands—or millions—of users.
From Damascus University to ManTek
Jaafar studied IT engineering with a focus on AI, which he describes as involving a lot of statistics and not much of what he eventually ended up doing professionally.
His path into technology and media took him to the UAE, where he joined Al Khaleej Newspaper.
Publishing has a rhythm you do not appreciate from outside: it never pauses, the deadlines are real, and when something is slow or wrong it is wrong in public.
That experience led to work with a television channel in Dubai Media City, where the systems became considerably deeper and the scale considerably larger.
AWS was already part of the technology stack when he arrived.
Rather than learning cloud technology through tutorials or isolated projects, he learned it while working on systems carrying real traffic.
AWS was already the stack when I arrived there, so I learned it the useful way, on a system that was already carrying real traffic.
For Jaafar, that became one of the biggest additions to his career.
WordPress came later, and interestingly, the reason wasn't primarily technical.
Management had decided to move away from depending on in-house systems.
Bespoke platforms can be expensive to build and maintain, while also creating a significant learning curve whenever a new developer joins the team.
WordPress offered something different: a platform developers already knew and could extend.
I think that reasoning is underrated.
Eventually, ManTek Technologies grew out of Jaafar having enough experience to be useful on his own, combined with a backlog of ideas he had been carrying around for years.
At some point, building those ideas became more interesting than leaving them unbuilt.
When Systems Fail Quietly
One of the recurring themes in Jaafar's work is silent failure.
A system that crashes is usually obvious.
A system that confidently gives you the wrong answer can be much more dangerous.
Because a failing check tells you it failed. A blind one hands you a clean, confident, wrong answer and lets you act on it.
One example came while auditing structured data on his own website.
A profile URL appeared to be returning a "Page not found" response. After checking it in a real browser and running automated checks for common bot-blocking behaviour, everything appeared normal.
So he removed the URL from twenty-two pages and began preparing the commit message.
Then he discovered the problem.
The profile actually existed.
The platform was simply serving logged-out visitors a page saying that it did not.
Nothing had timed out. Nothing had crashed. The check had not reported an error.
It had accurately reported the page it had been given—even though that page itself was misleading.
The instrument had not errored. It had truthfully reported on the page it was given, which happened to be a page about not finding things.
Once he recognised the pattern, he found five more examples in the same week.
There was an API field answering a different question than the one he intended to ask. A list endpoint disagreed with its own item endpoint. An analytics beacon could not be detected with curl for two independent reasons.
There were also editors that accepted a save and appeared to complete the operation while nothing actually reached disk.
That last failure was particularly painful.
A fully reviewed Arabic translation—forty-eight changed lines—existed nowhere except inside a browser tab.
The important lesson wasn't that these problems were technically difficult.
They weren't.
The danger is not that these are hard to fix. Every one was trivial to fix. The danger is that nothing asks you to look.
The 404 That Wasn't
Building for Arabic
One of the biggest challenges developers can underestimate when building for Arabic is that many assumptions in software were never explicitly written down.
That means when those assumptions break, the system may not necessarily tell you.
Jaafar highlights several examples.
Arabic URLs and Byte Limits
WordPress caps a new URL slug at 200 bytes in core through utf8_uri_encode( $title, 200 ).
For English, that budget roughly corresponds to 200 characters.
Arabic is different.
Because Arabic characters can require approximately six bytes after percent-encoding, the same limit can translate to roughly thirty-two characters.
A normal Arabic headline can exceed that easily.
The result can be a URL silently truncated in the middle of a word.
Even more concerning, this can affect URLs that have already been published.
Search
Arabic search introduces another class of problems.
WordPress search uses LIKE '%term%' over the post table, comparing raw bytes.
But Arabic contains optional diacritics, multiple written forms of letters such as alef and hamza, and characters such as tatweel, which can stretch a word without changing its meaning to a reader.
On a real archive containing 250,000 articles, Jaafar compared a search for:
مُحَمَّد
The results were striking:
| Search across 250,000 articles | Results | Time |
|---|
| WordPress | 1 | 4.8 s |
| With normalisation and an index | 28,238 | 0.55 s |
One result instead of more than twenty-eight thousand.
And again, there was no obvious error.
The editors experiencing the problem didn't necessarily report that search was broken.
They reported that it was slow.
Slow is the part you can feel.
Rendering Arabic
The challenges don't stop at encoding and search.
Jaafar also encountered an issue while generating images containing Arabic text.
He kept anchoring the text to the wrong edge.
The relevant attribute was text-anchor, where start does not necessarily mean "left". It means the start of the reading direction—which, for Arabic, is the right.
The library was behaving correctly.
His intuition was wrong.
The general lesson: if you build for a language you do not read, your tests will share your assumptions. Test with real content from real users.
WordPress Arabic Search
Scaling WordPress
Jaafar has worked with genuinely large Arabic newsroom traffic, and his lessons about scaling WordPress are less about simply throwing more resources at the application.
He identifies three major lessons.
The spike is rarely the interesting problem
A 20x traffic surge on a news story can sound terrifying.
But much of that traffic consists of identical anonymous requests that can be handled by caching.
The more interesting problems are the requests that cannot be cached.
Search.
Logged-in editorial traffic.
And the write path that still needs to publish content while everything else is happening.
Jaafar also makes an important clarification about the often-mentioned 50,000 concurrent-user figure:
It is load-tested, not an observed peak.
The test demonstrates that the cacheable path can hold up.
It says much less about the newsroom itself—and the newsroom is the part that keeps you awake.
Background jobs fail quietly
WordPress cron is another potential weak point.
Because cron is triggered by traffic, putting WordPress behind a load balancer can result in cron running on every server simultaneously—or on none of them.
Scheduled posts can fail to publish without necessarily producing an obvious alarm.
"Nothing happened" is not an event.
This is why one of Jaafar's open-source plugins elects a single cron runner across a fleet and raises an alert when it stalls.
Move work away from WordPress
Media processing is a good example.
Serving and resizing images directly from the application means the application is doing work that doesn't necessarily belong there.
Moving that work to object storage and an edge layer means the origin server becomes less sensitive to traffic spikes.
After five years of working with large-scale Arabic newsroom traffic, Jaafar sees a consistent pattern:
Uptime comes from having less of the system in the request path, not from tuning what is in it.
The Importance of Observability
For Jaafar, observability is slightly different from simply having logging and monitoring.
A system can have both and still fail silently.
The question he cares about is:
Can a check distinguish "this is fine" from "I cannot see this"?
Many systems cannot.
An uptime monitor hitting a homepage can tell you that the homepage renders.
It cannot tell you whether scheduled posts were published, whether email actually left the system, or whether search returned the correct records.
He experienced this distinction on his own website when two analytics counters for the same site and period disagreed by roughly two orders of magnitude.
Neither system was broken.
Neither was lying.
They were simply answering different questions.
One counted every request reaching the edge, including bots.
The other counted browsers that actually executed the measurement script.
Only one represented the number of people reading the site.
Using the wrong number would have overstated readership by approximately eighty times.
Before you trust a number, know what it counts. That is observability too, and it is the part nobody writes runbooks for.
His approach is therefore to alert on outcomes users would actually notice rather than simply monitoring whichever signal is easiest to collect.
Failures should be loud by design.
One of his plugins, for example, refuses to send mail when it is misconfigured rather than silently falling through to a transport that appears healthy but delivers nothing.
Refusing is friendlier than pretending.
Open Source and Real-World Problems
Jaafar has now released five open-source projects, each connected to the real-world problem that led to it.
For him, the connection between the diagnosis and the fix is important.
The fixes themselves are often small.
For example, wp-arabic-slug-schema-guard addresses the byte-budget problem around Arabic WordPress slugs.
But the valuable part isn't just the code.
It is understanding why the problem exists.
WordPress truncates at 200 bytes.
Arabic can consume approximately six bytes per character.
And published slugs can potentially be rewritten underneath an existing site.
A fix without that context is a snippet nobody trusts. The context without a fix is a complaint. Publishing both together is the only version that is actually useful to the next person.
The plugins are deliberately implemented as must-use plugins rather than ordinary plugins.
The reason is that infrastructure such as cron election and mail transport should not be something that can simply be switched off from an administrator screen.
There was even a lesson in the packaging of the plugins themselves.
Several plugins declared:
"type": "wordpress-muplugin"
so that Composer could install them into the correct directory.
But two of them did so without requiring composer/installers, the package responsible for interpreting that type.
In projects that already included the dependency, everything worked.
Elsewhere, Composer reported a successful installation but placed the plugin in vendor/, where WordPress never loaded it.
The installation succeeded.
The plugin simply did nothing.
Which was, ironically, exactly the kind of silent failure the plugins were designed to prevent.
What I learned from releasing them: the environment is the bug, almost every time.
Across six rounds of adversarial testing on one of the projects, every bug discovered involved either a check that could not fail or a silent wrong answer.
And none of those bugs were found simply by reading the code.
ManTek Technologies on GitHub
Building NUZ
Jaafar is currently developing NUZ, a cloud-native publishing platform aimed at high-traffic newsrooms.
He is careful to clarify its current status:
NUZ is pre-release. I am building the core, and there are no external partners on it yet.
That distinction matters.
The project is not being presented as a platform already running with external partners. It is still being built.
The problem NUZ is intended to address is the way many publishing platforms approach scale.
A newsroom might begin with a CMS designed for a blog.
Then caching is added.
Then a CDN.
Then a media pipeline.
Then a search layer.
Each addition introduces another component and another potential failure mode.
Eventually, the newsroom is maintaining an architecture that nobody originally designed as a whole.
NUZ starts from a different assumption:
The traffic is spiky, the content is Arabic, and the editorial team publishes continuously while all of that is true.
Engineering in the Real World
When working with production systems, clever solutions are not always the best solutions.
Jaafar learned this through experience.
One early fix involved copying a core function, changing one line, and shipping it.
It worked.
Then the underlying platform changed that function three times across three releases.
His copy quietly diverged from the original implementation.
Eventually, the bug that returned looked nothing like the problem he had originally fixed.
The better solution was to use a documented filter and replace only the transport.
No fork.
No duplicated implementation.
No code that needed to be kept in sync with the platform.
When the platform gives you a seam, take the seam. Never fork.
The broader lesson is simple:
Prefer the boring integration point that the platform promises to keep working over the clever one that happens to work today.
Advice for Developers
When asked what habit developers should develop to become better at building reliable systems, Jaafar offered a surprisingly simple answer.
Before you accept that a check found nothing, point it at something you know is there.
The idea is straightforward.
If you are checking whether a value appears in a file, first test the check against a file where you know the value exists.
If you are verifying that a record is absent, first query a record you know exists.
The goal is to establish that the check itself is capable of finding what it is supposed to find.
Because sometimes the most dangerous result isn't an error.
It is a perfectly clean "nothing found."
Final Thoughts
Jaafar's journey is a good example of how real engineering experience is often built in places that tutorials don't cover.
It is built in production systems.
In traffic spikes.
In unexpected platform behaviour.
In multilingual content.
In failed background jobs.
In analytics numbers that answer the wrong question.
And especially in the quiet failures that look like success.
His approach is ultimately less about making systems look impressive and more about making them honest.
A system should tell you when it doesn't know.
A check should prove that it can actually see what it claims to see.
And when a platform provides a supported way to extend it, use that instead of building something that will quietly drift away from the original system.
For developers working with real users and real production systems, those lessons can be worth far more than another tutorial.
About Developer Stories
Developer Stories is a CoderLegion series featuring developers from our community and exploring the real journeys behind the code—the challenges they have faced, lessons they have learned, projects they are building, and experiences that can help other developers grow.
If you have a developer journey, engineering lesson, project, or experience you'd like to share with the CoderLegion community, we'd love to hear from you.
