
  <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
      <title>Kamil Owczarek | Senior Full-Stack Engineer</title>
      <link>https://whoisarjen.com/pl/blog</link>
      <description>Senior Full-Stack Engineer specjalizujący się w wydajnym e-commerce, skalowalnej architekturze i optymalizacji wydajności. TypeScript, React, Next.js, Vue, Nuxt, PostgreSQL, Redis.</description>
      <language>pl</language>
      <managingEditor>kamilow97@gmail.com (Kamil Owczarek)</managingEditor>
      <webMaster>kamilow97@gmail.com (Kamil Owczarek)</webMaster>
      <lastBuildDate>Mon, 06 Apr 2026 08:00:00 GMT</lastBuildDate>
      <atom:link href="https://whoisarjen.com/pl/tags/architecture/feed.xml" rel="self" type="application/rss+xml"/>
      
  <item>
    <guid>https://whoisarjen.com/pl/blog/replacing-redis-with-postgres-cache-migration</guid>
    <title>Zastąpiliśmy Redisa PostgreSQL-em w cache&#39;owaniu — oto co z tego wyszło</title>
    <link>https://whoisarjen.com/pl/blog/replacing-redis-with-postgres-cache-migration</link>
    <description>Nasz cache na Redisie ciągle zrywał połączenia TLS, kładąc całą warstwę cache&#39;owania. Po benchmarku, który omal nie wysłał nas w złą stronę, przenieśliśmy się na PostgreSQL — ta sama wydajność, zero dropów, o jeden serwis mniej do utrzymania.</description>
    <pubDate>Mon, 06 Apr 2026 08:00:00 GMT</pubDate>
    <author>kamilow97@gmail.com (Kamil Owczarek)</author>
    <category>Caching</category><category>PostgreSQL</category><category>Redis</category><category>Performance</category><category>Architecture</category><category>Serverless</category><category>Migration</category>
  </item>

  <item>
    <guid>https://whoisarjen.com/pl/blog/hmac-timestamp-tokens-zero-trust-service-communication</guid>
    <title>Tokeny HMAC z timestampem: komunikacja zero-trust między twoimi własnymi serwisami</title>
    <link>https://whoisarjen.com/pl/blog/hmac-timestamp-tokens-zero-trust-service-communication</link>
    <description>Jak zabezpieczyliśmy komunikację między serwisami tokenami podpisanymi HMAC-SHA256, które wygasają po 10 sekundach — bez stanu sesji, bez kluczy API do rotowania, bez odpytywania bazy w middleware.</description>
    <pubDate>Sun, 15 Mar 2026 12:00:00 GMT</pubDate>
    <author>kamilow97@gmail.com (Kamil Owczarek)</author>
    <category>Security</category><category>HMAC</category><category>Architecture</category><category>Node.js</category><category>TypeScript</category><category>Microservices</category><category>Authentication</category>
  </item>

  <item>
    <guid>https://whoisarjen.com/pl/blog/splitting-monolith-into-services-fix-api-bugs</guid>
    <title>Kiedy podwojenie pamięci serwera to zły fix: jak rozdzielenie serwisów zakończyło nasz kryzys OOM</title>
    <link>https://whoisarjen.com/pl/blog/splitting-monolith-into-services-fix-api-bugs</link>
    <description>Nasza monolityczna aplikacja Nuxt regularnie wykładała się na limicie 2 GB pamięci. Podbiliśmy go do 4 GB — dwa razy drożej, ten sam problem u podstaw. Po pięciu dniach nieudanych optymalizacji (kompresja strumieniowa, polling po Redisie, cache SWR) rozbiliśmy monolit na trzy niezależne serwisy. Każdy dostał własne 2 GB, łączny koszt spadł, a crashe się skończyły.</description>
    <pubDate>Sat, 14 Mar 2026 12:00:00 GMT</pubDate>
    <author>kamilow97@gmail.com (Kamil Owczarek)</author>
    <category>Architecture</category><category>Nuxt</category><category>Nitro</category><category>Memory</category><category>Performance</category><category>Serverless</category><category>Vercel</category><category>TypeScript</category>
  </item>

  <item>
    <guid>https://whoisarjen.com/pl/blog/the-api-payload-trap-why-your-server-shouldnt-touch-the-bytes</guid>
    <title>Pułapka payloadu w API: dlaczego twój serwer nie powinien dotykać bajtów</title>
    <link>https://whoisarjen.com/pl/blog/the-api-payload-trap-why-your-server-shouldnt-touch-the-bytes</link>
    <description>Jak zastąpienie proxowania odpowiedzi API redirectami 307 do podpisanych URL-i CDN wyzerowało koszty transferu na origin i usunęło całą klasę bugów ze streamowaniem.</description>
    <pubDate>Wed, 11 Mar 2026 12:00:00 GMT</pubDate>
    <author>kamilow97@gmail.com (Kamil Owczarek)</author>
    <category>CDN</category><category>Performance</category><category>Architecture</category><category>API Design</category><category>Node.js</category><category>Caching</category><category>Security</category>
  </item>

  <item>
    <guid>https://whoisarjen.com/pl/blog/timestamp-based-cache-invalidation-swr</guid>
    <title>Inwalidacja cache&#39;a w O(1): flagi z timestampem zamiast kasowania kluczy</title>
    <link>https://whoisarjen.com/pl/blog/timestamp-based-cache-invalidation-swr</link>
    <description>Jak zastąpiliśmy powolne czyszczenie cache&#39;a po kluczach natychmiastową inwalidacją opartą na timestampach, nie tracąc przy tym wydajności SWR.</description>
    <pubDate>Sun, 28 Dec 2025 12:00:00 GMT</pubDate>
    <author>kamilow97@gmail.com (Kamil Owczarek)</author>
    <category>Performance</category><category>Redis</category><category>Caching</category><category>Nuxt 3</category><category>Architecture</category><category>SWR</category>
  </item>

  <item>
    <guid>https://whoisarjen.com/pl/blog/timezone-safe-datetime-global-applications</guid>
    <title>Obsługa daty i czasu odporna na strefy czasowe w aplikacjach globalnych</title>
    <link>https://whoisarjen.com/pl/blog/timezone-safe-datetime-global-applications</link>
    <description>Prosty kontrakt między frontendem a backendem na obsługę daty i czasu, który eliminuje bugi w harmonogramowaniu między strefami i uniezależnia aplikację od lokalizacji serwera.</description>
    <pubDate>Thu, 05 Jun 2025 16:00:00 GMT</pubDate>
    <author>kamilow97@gmail.com (Kamil Owczarek)</author>
    <category>DateTime</category><category>Timezone</category><category>UTC</category><category>JavaScript</category><category>Architecture</category><category>i18n</category>
  </item>

    </channel>
  </rss>
