KVN
System registry
SYS-009c. 2026–present

Armenia Pellazgjike

A managed digital publishing platform for books, translations, and cultural, historical, and linguistic studies, with a bilingual, indexable public library.

TypePlatformEngagementOwnedTierCase StudyStateProductionActivityActive Maintenance
Open Armenia Pellazgjike
01

Context

Armenia Pellazgjike gives a collection of books and related studies a maintainable publishing and delivery system. Django Admin manages publication and category records, translated metadata, visibility, featured state, covers, and documents. A Django REST API supplies a bilingual Next.js library with localized routes, discoverable book pages, and direct read/download access. I built and maintain the software platform; Berzh Vahram Piranjani remains the author of the books and research it presents.

Core engineering problem

Make an evolving collection of books and related written work publicly accessible without coupling every editorial change to frontend source code.

The product is a public library rather than an account or commerce system. It combines controlled editorial input, bilingual presentation, document delivery, and indexable pages while keeping the software contribution distinct from the authorship of the material it publishes.

  • Only active publications are exposed through the public library.
  • Site-interface locale and a publication's own language remain separate concepts.
  • Public cover images and book documents need different cache and access behavior.
  • Reading and downloading remain available without public accounts, checkout, or payment.
  • Public contact handling limits abuse without exposing visitor or submission records.
  • Cultural and historical interpretations remain attributed to the published author and works.
02

My role

I designed, implemented, deployed, and maintain the software platform, including its publication backend, public application, discoverability, document delivery, and operational boundaries.

Contribution boundaries

  • Content AuthorshipBerzh Vahram Piranjani is the author of the books, translations, studies, and other written works presented by the platform; my contribution is the software platform.
  • Research ClaimsCultural, historical, and linguistic interpretations are attributed to the author and published works rather than presented by the portfolio as established facts.
Architected

Platform And Domain Design

Publication catalogue, editorial workflow, public visibility, API, document access, contact handling, and system boundaries.

DesignedArchitectedModelledImplementedReviewed
Designed

Backend And Editorial Workflow

Django models, admin-managed publication data, translated fields, public API, read/download behavior, contact handling, and storage selection.

DesignedImplementedMaintainedReviewed
Implemented

Frontend And Discoverability

Bilingual Next.js delivery, localized routes, metadata, structured data, sitemap, robots, and revalidation.

ImplementedMigratedOptimizedMaintainedReviewed

Deployment And Maintenance

Containerized frontend/backend runtime, persistent catalogue and media state, hosting, software maintenance, and ongoing publication administration.

ImplementedDeployedOperatedMaintained

Collaboration credit

  • Berzh Vahram PiranjaniAuthor of the books, translations, studies, and other written works published through the platform.
03

Architecture

Level 01 / System

Managed publication and public delivery

09 boundaries · 09 declared relationships

  1. 01Author and editorial operatorClient
  2. 02Public readerClient
  3. 03Search engineExternal Client
  4. 04Bilingual Next.js public libraryService
  5. 05Django publication backend and APIAPI
  6. 06Publication catalogueDatastore
  7. 07Public cover storageDatastore
  8. 08Protected document storageDatastore
  9. 09Containerized application runtimeInfrastructure
Relationship mapInspect 09 connections
  • Author and editorial operatorRequestDjango publication backend and API
  • Django publication backend and APIPersistencePublication catalogue
  • Django publication backend and APIPersistencePublic cover storage
  • Django publication backend and APIPersistenceProtected document storage
  • Public readerRequestBilingual Next.js public library
  • Search engineRequestBilingual Next.js public library
  • Bilingual Next.js public libraryRequestDjango publication backend and API
  • Containerized application runtimeHostingBilingual Next.js public library
  • Containerized application runtimeHostingDjango publication backend and API
04

Engineering decisions

01

Keep publication data behind an editorial backend

Context

Books, categories, translated descriptions, files, and publication states need to change without rebuilding hard-coded page content.

Selected approach

Manage publication records and visibility in Django Admin and serve active records through Django REST endpoints.

Rationale

Keep editorial state separate from public presentation and allow content maintenance without frontend source changes.

Trade-offs

  • Public pages depend on API availability or cached/revalidated output.
  • Frontend and API fields must evolve together.
02

Separate site locale from publication language

Context

The public interface is Albanian/English while individual books may be written in a broader set of languages.

Selected approach

Use sq/en for localized interface routes and store the publication's own language independently on each book.

Rationale

Keep the interface intentionally bilingual while accurately describing works in other languages.

Trade-offs

  • Translation fallback must be consistent when localized metadata is incomplete.
  • Filters and labels must interpret two related language concepts.
03

Give covers and book files different storage behavior

Context

Cover images are public presentation assets, while book files need controlled access and different caching behavior.

Selected approach

Use public/cacheable cover storage and private, signed document storage when object storage is configured, with filesystem fallbacks locally.

Rationale

Match access and caching policy to the different purpose of each asset class.

Trade-offs

  • Storage configuration has more settings and migration concerns.
  • Local and object-storage paths need equivalent application behavior.
04

Make localized book pages indexable

Context

Public access depends on readers and search engines finding individual works, not only opening a client-side catalogue.

Selected approach

Use localized book routes with canonical and alternate metadata, structured data, sitemap entries, and controlled page revalidation.

Rationale

Treat discoverability as part of delivering a public library while allowing catalogue changes to appear without full frontend rebuilds.

Trade-offs

  • Metadata generation adds API fetches and fallback behavior.
  • Revalidation introduces a short delay before editorial changes appear everywhere.
05

Runtime ownership

  1. 01
    Containerization

    Separate production-oriented containers build and run the Next.js frontend and Django backend.

  2. 02
    Reverse Proxy

    Application services are loopback-bound behind a separate public-routing boundary.

  3. 03
    Hosting

    I host and actively maintain the production platform.

  4. 04
    Storage

    Persistent runtime storage protects catalogue and media state across application rebuilds.

    Inspect operational detail
    • Object storage can apply separate public-cover and protected-document policies when configured.
  5. 05
    Email

    The public contact form uses server-side delivery and abuse controls.

  6. 06
    Deployment

    Production startup applies database migrations before serving the backend and runs a production Next.js build separately.

06

Current state

  1. Current

    The bilingual public library is deployed in production and receives ongoing software and catalogue maintenance.

  2. Lesson

    Publishing systems benefit from separating editorial data from presentation.

  3. Lesson

    Discoverability is part of the product when the purpose is public access to written work.

  4. Lesson

    Public covers and protected document files have different storage and access needs.

  5. Lesson

    Site locale and publication language are different concepts and should stay separate.

Depth B / Technical inspection

Inspect supporting evidence

Domains, provider boundaries, and evidence classifications.

T1

Domain structure

  • Publications and categoriesBooks, categories, publishing metadata, year, ISBN, book language, page count, active state, and featured state.
  • Translated editorial metadataAlbanian-default translations for category names and selected subtitle, description, and publishing fields.
  • Editorial content managementAdmin-managed categories, publications, attached covers and files, visibility, featured state, and access records.
  • Public library deliveryAlbanian and English library and book-detail routes with category filtering and responsive presentation.
  • Document and media accessPublic/cacheable covers and separately handled book files for online reading and downloads.
  • Read and download recordsServer-owned access counters and records with repeated counter increments suppressed inside a short window.
  • DiscoverabilityLocalized canonicals and alternates, structured data, sitemap, robots, and revalidated indexable book pages.
  • Public enquiriesServer-delivered contact messages with rate-limited, blocked, and sent attempt states.
T2

Integrations

  • Media StorageS3-compatible object storage

    Apply separate cache and access behavior to covers and book documents when object storage is enabled.

    Environment-selected object-storage adapter
  • EmailTransactional email delivery

    Deliver public contact messages without placing provider configuration in the browser.

    Environment-configured server-side email
T3

Capability evidence

  • System architectureI designed the editorial backend, public application, data, document, discovery, and runtime boundaries.
  • API designI built publication, category, read/download, and contact endpoints around the public-library workflow.
  • Frontend deliveryI reworked and maintain the bilingual Next.js application and its localized publication pages.
  • Domain modellingI model publications, categories, translated metadata, visibility, media, access records, and public enquiries.
  • Systems integrationI keep object storage and server-side email behind application-owned configuration and interfaces.
  • Relational persistenceI persist publication, category, visibility, access, and contact-control records behind the Django application.
  • Deployment and operationsI deploy and actively maintain separate containerized frontend and backend services with persistent state.
  • Performance optimizationI use page revalidation, cover dimensions, image optimization, and cache-aware cover storage for public delivery.
  • Automated testingI maintain backend coverage for publication access, counters, cover failures, contact delivery, and abuse controls.