Update call sites for MathJax formulas to use double dollar signs 41929

Author: webstackdev

_TODO.md

@@ -116,28 +116,20 @@ https://mermaid.js.org/config/directives.html
 
 - See comp images in Breadcrumbs component directory for visual improvements
 
-- Text code blocks have weird formatting: `src/content/articles/cdn-edge-caching-cache-keys-vary-headers/index.mdx` that one seems like it should be some other kind of display, not a text code block.
+- Add Inset component and convert `text` code blocks to use it.
 
-- Need to stop system from adding abbreviation html when used in headings, also the `abbr` presentation needs improved - right now it gives a question mark pointer and long delay to appear
+- Need a Q & A format to use in `blameless-postmortem-incident-analysis-systemic-causes`. Might be one of the list formats.
 
 - Re-enable link validator in `astro.config.ts` when pdf / downloads sorted out
 
 - Add people who sign up for newsletter, download, or fill out contact form to Hubspot tracking. Need to configure it to remove them if they do the GDPR remove me. Also remove them from the newsletter.
 
-- Mathjax not working on inline formulas: "Where $L$ is the average number of items in the system (queue depth), $\lambda$ is the arrival rate (requests per second), and $W$ is the average time in system (latency)." In backpressure-load-shedding-admission-control-overload, also "The Retry Amplification Problem" section in circuit-breaker-retry-budget-cascade-failure-prevention.
-
 - Uppy, Tus server, whatever other server needed for file upload on Contact Form component
 
-- Need a Q & A format to use in `blameless-postmortem-incident-analysis-systemic-causes`
-
 - Use an in-project Image component to wrap Astro's Image and Picture. Show a magnifying glass with a "+" for the cursor on hover, and a modal to show a magnified view of images on click.
 
 - Add a copyright notice to content
 
-- DownloadLayout to wrap `downloads.mdx` in each folder
-
-- Image for home page newsletter CTA
-
 - Add PDF download image to download CTA, it's in the directory
 
 - Time in prose is causing a line break, and the colon and minutes to be removed - "2:47 AM" in `src/content/articles/mtls-certificate-rotation-service-mesh-authentication/pdf.mdx`. Times like "11:59:59" are breaking across two lines - `src/content/articles/rate-limiting-token-bucket-leaky-bucket-implementation/index.mdx` in "Algorithm Overview" section

src/content/articles/backpressure-load-shedding-admission-control-overload/pdf.mdx

@@ -74,7 +74,7 @@ $$
 L = \lambda \times W
 $$
 
-Where $L$ is the average number of items in the system (queue depth), $\lambda$ is the arrival rate (requests per second), and $W$ is the average time in system (latency).
+Where $$L$$ is the average number of items in the system (queue depth), $$\lambda$$ is the arrival rate (requests per second), and $$W$$ is the average time in system (latency).
 
 This equation is deceptively simple but has profound implications:
 

src/content/articles/circuit-breaker-retry-budget-cascade-failure-prevention/index.mdx

@@ -61,7 +61,7 @@ The database recovered at T+60s, but the cascade continued for another 9 minutes
 
 The math behind retry amplification is straightforward, and terrifying. Each service layer multiplies the load on the layer below it. If Service A retries 3 times, it sends 4 total requests (1 original + 3 retries) to Service B. If Service B also retries 3 times per request, each of those 4 requests generates 4 requests to Service C. The multiplication cascades down the stack.
 
-The formula is simple: $(r + 1)^n$ where $r$ is retries per service and $n$ is the number of services in the chain. With 3 services each retrying 3 times, that's $4^3 = 64x$ load amplification.
+The formula is simple: $$(r + 1)^n$$ where $$r$$ is retries per service and $$n$$ is the number of services in the chain. With 3 services each retrying 3 times, that's $$4^3 = 64x$$ load amplification.
 
 | Services in Chain | Retries Each | Load Amplification |
 |-------------------|--------------|-------------------|

src/content/articles/circuit-breaker-retry-budget-cascade-failure-prevention/pdf.mdx

@@ -65,7 +65,7 @@ The database recovered at T+60s, but the cascade continued for another 9 minutes
 
 The math behind retry amplification is straightforward, and terrifying. Each service layer multiplies the load on the layer below it. If Service A retries 3 times, it sends 4 total requests (1 original + 3 retries) to Service B. If Service B also retries 3 times per request, each of those 4 requests generates 4 requests to Service C. The multiplication cascades down the stack.
 
-The formula is simple: $(r + 1)^n$ where $r$ is retries per service and $n$ is the number of services in the chain. With 3 services each retrying 3 times, that's $4^3 = 64x$ load amplification. Bump the retries to 5 and you get $6^3 = 216x$.
+The formula is simple: $$(r + 1)^n$$ where $$r$$ is retries per service and $$n$$ is the number of services in the chain. With 3 services each retrying 3 times, that's $$4^3 = 64x$$ load amplification. Bump the retries to 5 and you get $$6^3 = 216x$$.
 
 The table below shows how quickly this gets out of hand. These numbers assume every request at every layer fails and triggers full retries—a worst case, but exactly what happens during a cascade failure:
 

src/content/articles/flaky-test-diagnosis-race-conditions-e2e-stabilization/index.mdx

@@ -15,7 +15,7 @@ featured: true
 *[API]: Application Programming Interface
 *[SPA]: Single Page Application
 
-A single test with a 5% flake rate will block CI once every 20 runs. That sounds manageable. But a suite of 100 tests where each has just a 1% flake rate? That suite will fail 63% of builds. The probability compounds: $(1 - 0.01)^{100} \approx 0.37$, meaning only 37% of builds pass cleanly.
+A single test with a 5% flake rate will block CI once every 20 runs. That sounds manageable. But a suite of 100 tests where each has just a 1% flake rate? That suite will fail 63% of builds. The probability compounds: $$(1 - 0.01)^{100} \approx 0.37$$, meaning only 37% of builds pass cleanly.
 
 I've watched this pattern destroy teams' ability to ship. A few random failures appear. The first response is always the same: "just retry and merge." Within a few months, nobody trusts red builds anymore. Developers stop investigating failures because it's faster to retry than debug. Then a real regression ships because the failure was dismissed as "probably flaky." That's when teams lose the ability to distinguish signal from noise.
 

src/content/articles/flaky-test-diagnosis-race-conditions-e2e-stabilization/pdf.mdx

@@ -21,7 +21,7 @@ featured: true
 
 Flaky tests—tests that sometimes pass and sometimes fail without any code changes—are one of the most insidious problems in test automation. They erode trust in your test suite, train developers to ignore failures, and eventually let real bugs slip through because "it's probably just flaky."
 
-The math is brutal. A single test with a 5% flake rate will block CI once every 20 runs. That sounds manageable. But a suite of 100 tests where each has just a 1% flake rate? That suite will fail 63% of builds. The probability compounds: $(1 - 0.01)^{100} \approx 0.37$, meaning only 37% of builds will pass cleanly.
+The math is brutal. A single test with a 5% flake rate will block CI once every 20 runs. That sounds manageable. But a suite of 100 tests where each has just a 1% flake rate? That suite will fail 63% of builds. The probability compounds: $$(1 - 0.01)^{100} \approx 0.37$$, meaning only 37% of builds will pass cleanly.
 
 I've watched this pattern destroy teams' ability to ship. A 200-test E2E suite starts showing random failures. The first response is always the same: "just retry and merge." Within a few months, nobody trusts red builds anymore. Developers stop investigating failures because it's faster to retry than debug. Then a real regression ships because the failure was dismissed as "probably flaky." The post-mortem reveals the team had lost the ability to distinguish signal from noise.
 

src/content/articles/kubernetes-hpa-autoscaling-metrics-tuning-latency/pdf.mdx

@@ -36,7 +36,7 @@ $$
 \text{desiredReplicas} = \text{currentReplicas} \times \frac{\text{currentMetric}}{\text{targetMetric}}
 $$
 
-If you have 3 replicas running at 75% CPU with a target of 50%, HPA calculates $3 \times (75/50) = 5$ replicas. The ceiling function ensures you always round up—better to have slightly more capacity than slightly less.
+If you have 3 replicas running at 75% CPU with a target of 50%, HPA calculates $$3 \times (75/50) = 5$$ replicas. The ceiling function ensures you always round up—better to have slightly more capacity than slightly less.
 
 ```mermaid
 sequenceDiagram
@@ -682,9 +682,9 @@ Code: Multi-metric HPA using CPU, RPS, and latency.
 
 Here's how the calculation works. Suppose current state is 5 replicas:
 
-- **CPU metric**: 60% utilization, target 50% → $5 \times (60/50) = 6$ replicas
-- **RPS metric**: 120 RPS/pod, target 100 → $5 \times (120/100) = 6$ replicas
-- **Latency metric**: 400ms P99, target 500ms → $5 \times (400/500) = 4$ replicas
+- **CPU metric**: 60% utilization, target 50% → $$5 \times (60/50) = 6$$ replicas
+- **RPS metric**: 120 RPS/pod, target 100 → $$5 \times (120/100) = 6$$ replicas
+- **Latency metric**: 400ms P99, target 500ms → $$5 \times (400/500) = 4$$ replicas
 
 HPA takes the maximum: 6 replicas. The latency metric calculates fewer replicas than currently running (4 < 5), which would suggest scaling down if it were the only metric—but CPU and RPS both want more capacity, so we scale up. This "max wins" behavior ensures you don't under-provision when _any_ metric indicates stress.
 

src/content/articles/postgresql-connection-pooling-saturation-sizing/index.mdx

@@ -33,9 +33,9 @@ Setting `max_connections` high "just in case" backfires. The database reserves m
 
 ## Sizing Pools with Math
 
-Pool sizing isn't guesswork—it's queuing theory. Little's Law provides the foundation: $L = \lambda \times W$, where $L$ is the average number of connections in use, $\lambda$ is the request arrival rate (queries per second), and $W$ is the average time per query.
+Pool sizing isn't guesswork—it's queuing theory. Little's Law provides the foundation: $$L = \lambda \times W$$, where $$L$$ is the average number of connections in use, $$\lambda$$ is the request arrival rate (queries per second), and $$W$$ is the average time per query.
 
-If your application handles 100 queries per second with an average query time of 50ms, you need $100 \times 0.05 = 5$ connections on average. Simple, right?
+If your application handles 100 queries per second with an average query time of 50ms, you need $$100 \times 0.05 = 5$$ connections on average. Simple, right?
 
 <Newsletter />
 

src/content/articles/postgresql-connection-pooling-saturation-sizing/pdf.mdx

@@ -244,9 +244,9 @@ Table: PgBouncer sizing by deployment scale.
 
 ### Sizing Calculations
 
-Pool sizing isn't guesswork—it's queuing theory. Little's Law provides the foundation: $L = \lambda \times W$, where $L$ is the average number of connections in use, $\lambda$ is the request arrival rate (queries per second), and $W$ is the average time per query.
+Pool sizing isn't guesswork—it's queuing theory. Little's Law provides the foundation: $$L = \lambda \times W$$, where $$L$$ is the average number of connections in use, $$\lambda$$ is the request arrival rate (queries per second), and $$W$$ is the average time per query.
 
-If your application handles 100 queries per second with an average query time of 50ms, you need $100 \times 0.05 = 5$ connections on average. But Little's Law uses averages, and averages deceive. Query times vary. Traffic spikes. A pool sized for average load will saturate during peaks.
+If your application handles 100 queries per second with an average query time of 50ms, you need $$100 \times 0.05 = 5$$ connections on average. But Little's Law uses averages, and averages deceive. Query times vary. Traffic spikes. A pool sized for average load will saturate during peaks.
 
 This is why the practical formula substitutes P99 query time for average: you want enough connections to handle 99% of queries without queueing, not just the typical case. Then double for variance and add burst capacity.
 
@@ -559,7 +559,7 @@ __Connections are expensive.__ Each connection costs 5-10MB of memory, consumes
 
 __Pooling decouples application scaling from database limits.__ PgBouncer (or similar external poolers) lets you scale application instances without proportionally increasing database connections. Transaction pooling mode handles most workloads well.
 
-__Size pools with math, not intuition.__ Little's Law ($L = \lambda \times W$) gives you a starting point. Account for variance with a burst factor. Anti-patterns like oversized pools ("just in case") create more problems than they solve.
+__Size pools with math, not intuition.__ Little's Law ($$L = \lambda \times W$$) gives you a starting point. Account for variance with a burst factor. Anti-patterns like oversized pools ("just in case") create more problems than they solve.
 
 __Monitor saturation, not just errors.__ By the time you see "too many connections" errors, you're already in a cascade. Set alerts on the utilization thresholds discussed earlier. Watch for idle-in-transaction sessions—they're connection leaks waiting to bite you.