
  <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>Sat, 14 Mar 2026 12:00:00 GMT</lastBuildDate>
      <atom:link href="https://whoisarjen.com/pl/tags/memory/feed.xml" rel="self" type="application/rss+xml"/>
      
  <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>

    </channel>
  </rss>
