Nabd El Djazair
نبض الجزائر — the pulse of Algerian news
A newsroom that publishes all day, on a platform that caches almost everything: an Arabic RTL news site engineered so speed, live view counts and a small database could coexist.
Nabd El Djazair (نبض الجزائر) covers national news, economy, technology, sport and society for an Algerian audience — a fully RTL Arabic product with dark editorial design.
We built the publishing platform end-to-end: category system, editorial dashboard, featured stories, per-article view counting and structured ad placements ready for direct sponsors.
The stack is tuned for news traffic: incremental static rendering keeps articles fast and indexable while the newsroom publishes continuously.
Where this started.
Algerian news lives on Facebook. A story breaks, a page posts a screenshot with a caption, and the link, if there is one, is an afterthought. That distribution reality shapes everything about building a news website here. The reader arrives from a shared post with roughly one screen's worth of patience, and if the article is slow they are already back in the feed. The site does not compete with other news sites first; it competes with the scroll it was pulled out of.
Nabd El Djazair (نبض الجزائر) was built to be a proper publication in that environment, covering national news, politics, economy, technology, sport, culture, health, society and international stories under one masthead, published continuously by a small editorial team. Arabic-first, right-to-left, dark by default: an editorial surface designed for reading rather than a template with the direction flipped.
The commercial reality mattered as much as the editorial one. The publisher's revenue plan is direct sponsors buying placements rather than programmatic display fill, so the site cannot rely on an ad network filling whatever gaps exist. It needs fixed, named, standard-sized inventory that a sales conversation can point at, present on every page, and visible as reserved space even before a sponsor is signed.
What actually made this hard.
News traffic is spiky and cache-hostile
A publication is quiet for hours, then a single story pulls a surge of readers from one shared post. Rendering every one of those requests from the database is the naive path to a dead site at the exact moment it matters. But news also changes by the minute, so aggressive caching risks serving readers a front page that is already stale.
View counts and static caching are in direct conflict
Readers and sponsors both want to see how many people read a story, but a page served from cache is by definition a page the server did not render, so it cannot count anything. Every naive fix makes it worse: incrementing on render inflates the count with cache warms, and displaying a locally guessed number makes the site quietly lie about its own audience.
The database ceiling shaped the architecture
The platform runs against a managed Postgres instance with a hard, low ceiling on simultaneous connections. Under a deploy or a traffic spike, a framework that opens connections freely will exhaust that ceiling and take the whole site down, not slowly degrade but fail outright. The connection budget had to be treated as a first-class design constraint rather than a configuration detail.
Right-to-left is not a stylesheet flip
Arabic editorial design touches layout direction, typography, numerals, icon orientation, card and carousel logic, ad-slot alignment and the reading rhythm of a headline. A site built left-to-right and mirrored at the end always shows its seams: misaligned metadata, arrows pointing the wrong way, Latin-shaped type on Arabic text. The direction had to be the starting assumption, from the first component.
A newsroom cannot wait for a developer
Editors publish several times a day, promote a story to the front page, fix a headline, attach an image from a phone. Any workflow that requires a deploy or a database query is a workflow that will be abandoned within a week, and the publication would quietly revert to posting on Facebook.
How we ran it.
We built Nabd El Djazair as a Next.js application where almost every reader-facing page is statically rendered and revalidated on a schedule tuned per page type: a front page that refreshes on a short interval because it is a river of news, article pages on a longer one because a published story rarely changes. A reader arriving from a shared link gets a page that was already built before they asked for it, while the newsroom keeps publishing continuously behind it.
The consequence of that decision is that everything genuinely live has to be handled deliberately, as an exception on top of a static base. View counting became the interesting case, and the database connection ceiling became the discipline that governed every data-access decision we made afterwards.
Editorial model and taxonomy
We defined the section structure with the newsroom, covering national, society, politics, economy, technology, sport, culture, health and international alongside the front page, plus the concepts editors actually use day to day: featured stories, highlighted items, per-section counts and article metadata. Getting the taxonomy right early is what let both the reader navigation and the dashboard be generated from the same structure.
RTL editorial design system
We designed dark-first in Arabic, starting from a real headline and a real byline rather than Latin placeholder text. Section pills, article cards, the featured hero, the section sidebar with live counts, badges for featured stories, view and date metadata in Arabic numerals: every component was built direction-aware from the outset, with a light-mode toggle for readers who prefer it.
Platform and editorial dashboard
We built the publishing side: article authoring with images, section assignment, featured and highlighted flags, and the editorial controls a small team needs to run a front page without touching code. Images are uploaded to object storage behind a CDN rather than living beside the application, so publishing a photo-heavy story does not tax the database or the server.
Caching, view counting and connection discipline
We tuned incremental static regeneration per page type, then solved view counting on top of it as a client-side increment that returns the authoritative count from the server, so the number the reader sees is the number the database holds. In parallel we capped the connection budget per running instance and moved schema synchronisation into the build step so a deploy could never contend with live traffic for connections.
Monetisation surface and launch
We placed reserved, standard-sized ad inventory, a leaderboard above the fold and a rectangle in the sidebar with a mobile counterpart for each, labelled clearly as available placement so the publisher can sell against visible space. The site went live with the full section structure populated and a growing archive of published articles.
Everything that shipped.
Reader experience
- Fully right-to-left Arabic interface, dark by default with a light toggle
- Featured hero story with section and highlight badges
- Section navigation with live per-section article counts
- Latest-news river and per-section archives
- Per-article view count and Arabic-numeral publication dates
- Site-wide search across the archive
Editorial dashboard
- Article authoring with image upload to CDN-backed object storage
- Section assignment across the full taxonomy
- Featured and highlighted flags that drive front-page composition
- Edit and correct published stories without a deploy
- Authenticated accounts scoped to the editorial team
Performance and SEO architecture
- Incremental static regeneration tuned per page type
- Bounded database connection budget per running instance
- Schema synchronisation at build time, never on cold start
- Client-side view counting that survives static caching
- Arabic-language metadata and structured data for article indexing
- Image delivery through object storage and a CDN, decoupled from the database
Monetisation
- Reserved leaderboard placement above the fold, with a mobile counterpart
- Reserved sidebar rectangle, with a mobile counterpart
- Placements labelled as available inventory before sponsors are signed
- Standard display unit sizes so direct sponsors can supply existing creative
- Slots positioned to survive the static caching model without layout shift
The calls we made, and what they cost.
Every decision here bought something and gave something up.
Counting views on pages the server never rendered
Because article pages are statically generated and revalidated on an interval, the server does not execute on most reads, so it cannot increment anything, and any count derived from render events would measure cache warms rather than readers. We moved the increment to the client: on load, the article component issues a small write request and the API responds with the new authoritative total, which the component then displays. The trade-off is explicit and we made it knowingly, because this counts page loads rather than deduplicated humans. We deliberately refused the two tempting shortcuts, optimistically displaying the stored count plus one and deduplicating in browser session storage, because both make the site display a number the database does not hold. An honest, slightly generous counter beats a flattering, unverifiable one, especially when sponsors read it.
The connection budget as a design constraint
The managed Postgres behind the site has a hard ceiling on simultaneous connections, and the platform's default behaviour under horizontal scaling is to open a fresh pool per instance until the ceiling is gone and every request fails at once. We pinned a deliberately small per-instance connection limit with an explicit pool timeout, so an instance queues briefly under load instead of the cluster refusing connections outright. The trade-off is that we accept a small amount of request queueing at peak in exchange for never hitting the cliff, because a slower request is recoverable and an exhausted connection pool is an outage.
Schema synchronisation at build, not at cold start
Running schema synchronisation when the application boots means every new instance opens an administrative connection at exactly the moment traffic is highest, which is the same moment the connection budget is tightest. We moved it into the build step instead, so the database shape is settled before any instance serves a request and runtime connections are only ever used for reading and writing content. The trade-off is that a schema change now requires a build rather than a restart, which is the correct direction for a production publication anyway.
Per-page-type revalidation intervals
The front page and an article page have different truth decay rates, so we gave them different revalidation windows: a short interval for the front page, which must reflect a newsroom publishing continuously, and a longer one for article pages, which rarely change after publication. The trade-off a publisher must understand is that a correction to a live article is not instantaneous for every reader, since it propagates on the next revalidation. We considered that acceptable against the alternative, which is rendering every article view against a database with a strict connection ceiling.
Direction-aware components instead of a mirrored stylesheet
Every layout primitive was authored with right-to-left as the default rather than as an override: logical properties instead of hard-coded left and right, direction-aware carousels and icon orientation, Arabic numerals in metadata, and type sizing chosen against real Arabic headlines. The cost is that the component library is more opinionated and less portable to a left-to-right project. The benefit is a site that reads as a native Arabic publication rather than a translated one, which is exactly the difference readers notice and cannot articulate.
Where it landed.
Nabd El Djazair runs as a working publication. A small editorial team publishes across the full section structure from a dashboard rather than through a developer, promotes stories to the front page themselves, and has accumulated a substantial archive under a single masthead. The section counters on the site are the plainest evidence of that, since they are read directly from the article table rather than typed in by hand.
Architecturally, the site does what it was built to do: absorb a spike from a shared link without translating that spike into database pressure. The connection ceiling that could have made this project fragile instead became the organising constraint, forcing a static-first reading path, a disciplined data layer and a deploy process that cannot contend with live traffic. That is a healthier system than one built on a generous database and never tested against its limits.
Commercially, the publication now has inventory it can sell. The leaderboard and sidebar placements are present on every page at standard unit sizes, visibly reserved, so a sales conversation with a direct sponsor is about a placement a client can see rather than a hypothetical one. For a publisher whose plan is direct sponsorship rather than network fill, having named, standard-sized, always-present inventory is the difference between a website and a media business.
Any publisher considering this architecture should weigh the revalidation window first. Statically generated article pages are what let a small database survive a viral link, but they also mean an edit is not instantly visible to every reader. For a news site that occasionally needs to correct a live story, that is a real cost, and the honest answer is that it is a cost worth paying at this scale, because the alternative is a site that is fully live and fully down whenever it matters most. If traffic and budget grow, the upgrade path is a proper connection pooler in front of the database, which would let us shorten those windows without touching the ceiling.
The view counter deserves the same candour. It counts page loads and does not deduplicate a reader who opens the same article twice, and we chose that over the clever alternatives because every clever alternative displays a number the database cannot confirm. If the publication later sells on audited audience figures, the correct next step is not a smarter counter but a proper analytics layer alongside it, one that measures sessions and leaves the on-page number as what it honestly is, a reading count.
Questions about this project.
Start right-to-left rather than converting to it. That means authoring components with logical properties instead of fixed left and right values, choosing type sizes against real Arabic headlines, orienting icons and carousels with the reading direction, and rendering metadata in Arabic numerals. A mirrored left-to-right template is always detectable through misaligned bylines, arrows pointing the wrong way and Latin-tuned line heights, and Arabic readers notice immediately even if they never name the reason.
You cannot count on the server, because a cached page is one the server never rendered. The workable pattern is a small client-side write on page load, with the API returning the authoritative new total for display, so the number on screen matches the number in the database. Avoid the shortcuts of showing a stored count plus one, or deduplicating in browser storage, because both display a figure the database cannot confirm, which is exactly what you do not want when a sponsor asks where it came from.
Yes, if the reading path is static. With incremental static regeneration tuned per page type, a spike from a shared social link is served from pre-built pages instead of hitting the database once per reader. The discipline that goes with it is bounding your database connections per instance and running schema changes at build time, so a deploy during a spike never competes with readers for the same limited connection budget.
Through direct sponsors rather than programmatic fill, since network display rates in the local market are not what funds a newsroom. Practically that means designing fixed, standard-sized placements, a leaderboard and a sidebar rectangle with mobile counterparts, that are present and visibly reserved on every page, so a sales conversation points at real inventory. Standard unit sizes matter because a sponsor can then supply creative they already have.
