<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>redis &#8211; Gig City Geek</title>
	<atom:link href="https://gigcitygeek.com/tag/redis/feed/" rel="self" type="application/rss+xml" />
	<link>https://gigcitygeek.com</link>
	<description>Gig powered, curiosity driven...</description>
	<lastBuildDate>Fri, 28 Aug 2026 17:01:49 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=7.1</generator>

<image>
	<url>https://gigcitygeek.com/wp-content/uploads/2026/01/cropped-GigCityGeek_Logo-32x32.png</url>
	<title>redis &#8211; Gig City Geek</title>
	<link>https://gigcitygeek.com</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>Flux: The Media Server Built From Discontent</title>
		<link>https://gigcitygeek.com/2026/09/03/the-monolith-creep-and-the-repeating-pattern-in-software-history/</link>
					<comments>https://gigcitygeek.com/2026/09/03/the-monolith-creep-and-the-repeating-pattern-in-software-history/#respond</comments>
		
		<dc:creator><![CDATA[Laronski]]></dc:creator>
		<pubDate>Thu, 03 Sep 2026 13:00:00 +0000</pubDate>
				<category><![CDATA[Smarter Not Harder]]></category>
		<category><![CDATA[Software]]></category>
		<category><![CDATA[fastify]]></category>
		<category><![CDATA[microservices]]></category>
		<category><![CDATA[monolith creep]]></category>
		<category><![CDATA[nodejs]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[prisma]]></category>
		<category><![CDATA[redis]]></category>
		<category><![CDATA[software history]]></category>
		<category><![CDATA[stack rebuilding]]></category>
		<category><![CDATA[transmission]]></category>
		<guid isPermaLink="false">https://gigcitygeek.com/?p=4578</guid>

					<description><![CDATA[The trend of rebuilding the same stack in software development is a phenomenon often referred to as the 'Monolith Creep'. This pattern of behavior is repeate...]]></description>
										<content:encoded><![CDATA[I recall back when spinning up a home media setup meant fighting with driver dependencies on a noisy desktop tucked away in a closet. Nowadays, tech hobbying is a time you love to waste, tinkering for hours just to replicate what a ten-dollar streaming service does out of the box. Looking at projects like Flux, I find myself asking why we keep rebuilding this exact stack every few years. The Monolith Creep Strikes Again My mini rig in the office is already running enough services to light up a small IT department. When I look at a repository pulling together Node, Fastify, Prisma, PostgreSQL, Redis, Transmission, and Next.js, my first instinct is to wince at the overhead. Why do we need a full enterprise microservices footprint just to stream an MP4 file across the local network? Yet, when you look at how job queues handle background processing, the design starts making sense. Offloading tasks to BullMQ keeps the main interface snappy while the server deals with background work. Still, the minimalist in me misses the simplicity of a single binary that just reads a directory and serves video files over HTTP without asking for a database password. Software History Keeps Repeating We used to build monolithic home theater PCs, then we split everything into separate backends and specialized clients, and now we are right back to all-in-one platforms trying to handle acquiring, indexing, and playing media under one roof. Tying BitTorrent capabilities directly into the core app always feels risky because external protocols change.Using sidecar containers helps isolate those risks, but history shows that sprawling platforms usually suffer from feature creep. Hardware Limits Meet Real World Video Direct play versus live transcoding is where theoretical software architecture hits actual hardware limits. If a browser native player can decode the video file, everything stays cool and quiet. If it cannot, FFmpeg fires up on the server to convert the stream into HLS on the fly.I tested this on my setup last weekend while streaming a high-bitrate file to a tablet in another room. The CPU spikes were instant. The digital archivist in me wants to preserve original bitrates, but anyone else watching just wants the video to start without endless buffering icons. Balancing Security With Actual Usage Managing access for family turns into an administration puzzle pretty fast. Separate profiles are great for keeping watch histories distinct, especially when you do not want your own continue-watching row filled with shows you never plan to finish. However, locking everything behind mandatory invite codes creates unnecessary friction. My wife just wants to open a link and hit play on a movie, not manage credentials or ask me to generate a single-use code every time a new device connects.Balancing a single-binary media setup against a feature-packed web platform always comes down to personal tolerance for maintenance. We will probably keep rebuilding these media stacks forever, simply because the process of tweaking the system is half the fun.]]></content:encoded>
					
					<wfw:commentRss>https://gigcitygeek.com/2026/09/03/the-monolith-creep-and-the-repeating-pattern-in-software-history/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
	</channel>
</rss>
