Microservices Architecture Explained: A Performance Testing & Resilience Engineering Playbook

Here’s a scenario that’s probably hit close to home. Your team ships a microservices-based platform that passed every functional test, every integration check, every staging smoke test. Then the first real traffic spike arrives – a marketing email, a flash sale, a Monday-morning login surge – and the whole thing buckles. Not because any single service crashed outright, but because one slightly slow service quietly dragged everything downstream into a tarpit. Latency climbed, timeouts fired, clients retried, and within ninety seconds you had a self-inflicted outage that no green test suite ever warned you about.

That gap is the whole problem. Most microservices content stops at definitions and tidy best-practice lists, which leaves you knowing what a circuit breaker is without ever being able to prove yours works under load. This guide takes the opposite approach. It connects architecture decisions directly to how systems behave – and break – when real concurrency hits, then shows you how to deliberately reproduce, test, and prevent the failures that only emerge under load.

Here’s the roadmap: we’ll reframe the architecture through a performance lens, dissect the three failure modes that functional tests never catch, turn resilience patterns into things you can actually test, walk a step-by-step testing methodology with reproducible scripts and SLO tables, and use distributed tracing as a diagnostic rather than just a dashboard. We’ll close with concrete industry scenarios. One honest note before we start: no tool makes resilience “hands-off.” AI accelerates correlation and anomaly detection, but human judgment stays in the loop for every meaningful decision.

1. Microservices Architecture Through a Performance Lens (Not Just a Definition)
   1. Service Boundaries, Bounded Contexts, and Why They Matter Under Load
   2. Synchronous vs. Asynchronous Communication: REST, gRPC, and Message Queues
   3. Monolith vs. Microservices: A Performance & Failure-Behavior Comparison
2. The Three Failure Modes That Only Show Up Under Load
   1. Cascading Failures: When One Slow Service Takes Down Everything
   2. Latency Amplification: The p99 Fan-Out Problem
   3. Retry Storms: The Self-Inflicted DDoS Engineers Keep Misdiagnosing
3. Resilience Patterns and How to Actually Test Them
   1. Circuit Breaker Testing: Closed, Open, and Half-Open States
   2. Retry Budgets, Jitter, Bulkheads, and Backpressure
   3. Chaos Engineering & Graduated Fault Injection Under Load
4. A Step-by-Step Microservices Performance Testing Methodology
   1. Map Dependencies and Define Per-Service SLOs
   2. Multi-Protocol Load Testing: HTTP, gRPC, WebSockets, and Async Messaging
   3. Isolation vs. End-to-End Testing and Dependency Mocking
   4. Integrating Performance Gates into CI/CD
5. Using Distributed Tracing as a Testing Diagnostic, Not Just Monitoring
   1. How Trace IDs and Spans Reveal the Failing Hop
   2. Where AI Anomaly Detection Adds Value (and Where Humans Still Decide)
6. Real-World Microservices Testing Scenarios
   1. E-Commerce: Cart, Inventory, Payment, and Shipping Under Peak Load
   2. Event-Driven & Compliance-Heavy Systems: Financial Services and Healthcare
7. Frequently Asked Questions
   1. What are microservices in simple terms, and what’s the difference from a monolith?
   2. How do you performance test microservices, and what protocols and tools are involved?
   3. Is testing microservices in isolation enough, or do I always need end-to-end tests?
   4. Why do my microservices pass functional tests but fail under real traffic?
   5. Should I add jitter or remove retries to stop retry storms?
8. References

Microservices Architecture Through a Performance Lens (Not Just a Definition)

Martin Fowler’s canonical framing describes microservices as an architectural style that structures an application as a suite of small, independently deployable services, each running in its own process and communicating over lightweight mechanisms [1]. You already know that. What matters for your job is that every one of those design choices – process isolation, network communication, independent deployment – changes the failure surface of your system.

In a monolith, a function call to another module costs nanoseconds and either succeeds or throws in-process. Decompose that same call across a network boundary and you’ve traded a nanosecond function call for a network round trip measured in single-digit-to-tens of milliseconds, plus serialization, plus the possibility that the other end is slow, overloaded, or simply gone. Multiply that across a request that touches eight or ten services and the architecture’s performance profile becomes a distributed-systems problem, not an application problem. That’s the lens that matters: the question isn’t “what are microservices,” it’s “how does this topology amplify latency and propagate failure?”

Service Boundaries, Bounded Contexts, and Why They Matter Under Load

Domain-driven design gives us bounded contexts – logical boundaries where a particular model and language apply. Drawing service boundaries along those contexts is sound design. Drawing them badly is a performance tax you pay on every request.

Here’s a concrete example. Suppose a “render product page” action needs product details, pricing, inventory, and reviews. If those live in four separate services and your page-assembly service calls each one sequentially, a single user action becomes four network hops. At a conservative 8ms per round trip on a healthy network, that’s 32ms of pure network overhead before any service does real work. Place the boundary worse – say, pricing has to call inventory, which calls a tax service – and you’ve turned one user action into six or seven chained hops. Every misplaced boundary adds hops, and every hop adds latency and a new place to fail. The fix is boundary design that keeps high-frequency interactions inside a single context, reserving network calls for genuine domain seams.

Synchronous vs. Asynchronous Communication: REST, gRPC, and Message Queues

The communication pattern you pick determines how latency and failure travel. HTTP/REST is universal and easy to debug, but text-based JSON serialization and per-request connection overhead make it the heaviest option for high-frequency internal calls. gRPC runs over HTTP/2 with Protobuf binary serialization and connection multiplexing, so it typically cuts payload size and per-call overhead significantly for chatty service-to-service traffic, and it supports streaming where REST forces polling [2]. WebSockets maintain a persistent bidirectional connection – great for real-time push, but each open socket consumes server memory and file descriptors, so 50,000 concurrent sockets is a capacity-planning problem, not a free lunch. As covered in our guide to testing WebSocket applications, validating these persistent connections at scale requires dedicated tooling. Messaging protocols like AMQP or Kafka decouple producers from consumers entirely; the upside is that a slow consumer doesn’t block the producer, the downside is that backlog accumulates silently as consumer lag until it becomes a problem you discover hours later.

The performance distinction is sharp: synchronous chains propagate latency and failure instantly – if service C stalls, services B and A stall waiting on it. Asynchronous flows absorb spikes into a queue but introduce backlog risk and eventual-consistency complexity.

Monolith vs. Microservices: A Performance & Failure-Behavior Comparison

Cloud-vendor comparisons tend to list features – independent deployability, technology diversity, scaling granularity [3]. Useful, but they skip the part you actually care about: how each architecture behaves under load and how it dies.

Dimension	Monolith	Microservices
Deployment frequency	Whole app per release; slower cadence	Per-service; teams can ship many times daily
Failure blast radius	One process crash takes the whole app	Failure isolated to a service – unless it cascades
Inter-service latency overhead	~0 (in-process calls)	Adds network + serialization cost per hop
Scaling granularity	Scale the entire app	Scale only the hot service
Dominant failure mode	Single point of failure	Cascading failure, latency fan-out, retry storms

The honest verdict – and Fowler’s “monolith first” principle agrees – is that you should choose a monolith when your domain boundaries aren’t yet clear, your team is small, and your traffic doesn’t demand independent scaling [1]. Microservices buy you deployment independence and scaling granularity at the cost of distributed-systems failure modes you now have to engineer against and test for. A lesson learned the hard way on more than one migration: teams that split a monolith before understanding its true seams end up with a “distributed monolith” – all the network cost, none of the independence.

The Three Failure Modes That Only Show Up Under Load

This is the diagnostic core of the playbook. Cascading failures, latency amplification, and retry storms share one trait: they’re nearly invisible at low traffic and devastating at scale. Functional tests run a request or two and see green. These failures need concurrency to manifest, which is exactly why load testing concurrent users – not unit testing – is where you catch them.

Cascading Failures: When One Slow Service Takes Down Everything

The Google SRE Book defines it precisely: “A cascading failure is a failure that grows over time as a result of positive feedback. It can occur when a portion of an overall system fails, increasing the probability that other portions of the system fail” [4].

Walk the loop. Imagine a fleet of storage servers that depend on a metadata service. The metadata service gets briefly overloaded and starts responding slowly. Storage servers hit their timeout and resubmit the request – now the metadata service is handling its original load plus a flood of resubmissions. That extra load pushes response times higher, which trips more timeouts, which triggers more resubmissions. The feedback loop is positive: each failure increases the probability of the next. Within seconds the metadata service is saturated, every dependent storage server is blocked waiting, and a single slow service has taken down the cluster.

The counterintuitive trap, as analysis from HdM Stuttgart notes, is that “intelligent” customizations like custom load balancing can actually increase total-failure risk – because clever redundancy logic often synchronizes the very retry behavior that feeds the loop [5]. The mitigations the SRE Book prescribes – load shedding, graceful degradation, capacity headroom – only matter if you’ve tested them under the load that triggers the cascade in the first place.

Latency Amplification: The p99 Fan-Out Problem

Here’s the math that should change how you set SLOs. Dean and Barroso’s The Tail at Scale documents it exactly: “Variability in the latency distribution of individual components is magnified at the service level” [6]. Their canonical example – consider a service where each server responds in 10ms typically but with a 99th-percentile latency of one second. If a request hits just one such server, one in 100 is slow. But “if a user request must collect responses from 100 such servers in parallel, then 63% of user requests will take more than one second” [6].

Read that again. A per-server p99 of 1 second, fanned out across 100 parallel calls, means the majority of your user requests are slow. The paper records a real Google service where the 99th-percentile latency for a single leaf request is 10ms but climbs to 140ms once all requests must complete [6]. This is why mean latency is a dangerous metric in microservices – averages hide the tail, and the tail is what your users feel. As we explain in the performance metrics that matter, your load tests must measure full distributions (p95, p99) under realistic fan-out, because amplification only appears when concurrency forces many slow-tail events to coincide.

Retry Storms: The Self-Inflicted DDoS Engineers Keep Misdiagnosing

The retry storm is the failure mode teams most consistently misdiagnose, because the symptom – a service that won’t recover – points away from the cause – the clients trying to help it recover. The sequence: a service degrades briefly, requests fail, and clients all begin retrying for, say, ninety seconds with identical exponential backoff and no jitter. Because their backoff timers are synchronized, every client retries at the same instant, slamming the recovering service with a thundering herd precisely when it has the least capacity. Recovery becomes the outage.

The Google SRE Book quantifies the amplification: 100 QPS of retries in the first second leads to 200 QPS, then 300, and so on – retries destabilize the system rather than rescue it [4]. The fix isn’t to remove backoff. As AWS Distinguished Engineer Marc Brooker puts it bluntly: “The solution isn’t to remove backoff. It’s to add jitter” [7]. His reproducible simulator shows the impact: “In the case with 100 contending clients, we’ve reduced our call count by more than half” simply by adding full jitter [7]. Pair that with retry budgets – the SRE Book recommends a server-wide retry budget capping retries as a fraction of request volume – and the storm never forms [4]. The key testing insight: you can only validate this by simulating synchronized retries under load, which a functional test will never do.

Resilience Patterns and How to Actually Test Them

Software resilience engineering is the applied descendant of a safety-science discipline. Erik Hollnagel’s “concepts and precepts” framework and David Woods’ work on how complex systems adapt to disturbance gave us the vocabulary; software engineers translated it into circuit breakers, retry budgets, and bulkheads. The point of resilience engineering isn’t to prevent all failure – it’s to ensure the system degrades gracefully rather than collapsing. And a pattern you can’t test is just a hope.

Circuit Breaker Testing: Closed, Open, and Half-Open States

Martin Fowler’s canonical pattern describes three states you must test as transitions, not as static configurations [8]. Closed: requests flow normally while the breaker counts failures. Open: once a threshold trips – say, the breaker opens after 5 failures within a 10-second window – requests fail fast without hitting the troubled service, giving it room to recover. Half-open: after a cooldown, the breaker lets a trial request through; success closes it, failure re-opens it.

To test this properly, inject controlled faults into the downstream dependency and assert the transitions. Using a library like Resilience4j, you configure the failure threshold and sliding window, drive failures past the threshold under load, and verify the breaker opens. Then assert the fallback behavior: when the circuit is open, your fallback should return fast – target a fallback latency under 50ms, because the entire value of failing fast evaporates if your fallback path is slow. Finally, restore the dependency and confirm the half-open trial closes the circuit. If you’ve never watched these transitions fire under concurrent load, you don’t actually know your breaker works.

Retry Budgets, Jitter, Bulkheads, and Backpressure

These patterns contain the spread of failure. Jittered exponential backoff breaks the synchronization behind retry storms – use full jitter, per AWS’s simulator data [7]. Retry budgets cap retries as a fraction of traffic; a common rule is to allow retries to consume no more than 10% of request volume, after which retries are dropped to protect the downstream service [4]. Bulkheads isolate resource pools so one failing dependency can’t drain shared threads – for example, give your payment-gateway calls a dedicated connection pool of 20 connections, separate from the 100-connection pool serving everything else, so a stalled payment provider can’t starve the rest of your service. Backpressure and rate limiting shed load gracefully under overload rather than letting queues grow unbounded. Test each by recreating the overload condition and asserting that the containment holds – that the bulkhead’s bounded pool fills and rejects rather than blocking the whole service.

Chaos Engineering & Graduated Fault Injection Under Load

Most chaos content recycles the same Chaos-Monkey-kills-a-pod story. The technique that actually validates resilience is graduated fault injection run with realistic concurrent load – because the failure loops above only form under traffic. Inject faults in a vacuum and you learn nothing about retry storms or latency amplification. For a deeper treatment with real-world examples, see our guide to chaos testing.

Frame every experiment scientifically. Here’s a worked one. Steady-state hypothesis: under 5,000 concurrent users, checkout success rate stays above 99.5% and checkout p99 stays under 300ms. Injected fault: add +200ms latency to the payment service. Blast radius: limited to 5% of checkout traffic, single staging cluster. Abort condition: if overall error rate exceeds 2% or p99 exceeds 1s, kill the experiment automatically. Now run it. If your circuit breaker and timeout strategy work, the +200ms is absorbed and the hypothesis holds. If checkout collapses, you’ve found a cascade path before production did. A graduated playbook escalates from latency injection to dependency failure to resource exhaustion to network partition, each under load, each with a hypothesis. Open-source tooling like Litmus or Chaos Mesh handles the injection mechanics; the Principles of Chaos Engineering provide the discipline’s foundation [9].

A Step-by-Step Microservices Performance Testing Methodology

Best-practice listicles tell you to “map dependencies and define SLOs.” This section actually walks it. And one structural warning the practitioner community keeps raising: microservices teams “deploy more often in small patches,” which means UI-only or HTTP-only test suites become a maintenance nightmare and miss the protocol diversity entirely [10]. You need a methodology built for heterogeneity.

Map Dependencies and Define Per-Service SLOs

Start by drawing the actual call graph for your critical user journeys. For a checkout flow: API Gateway → Cart Service → Inventory Service → Payment Service → Shipping Service, with the Cart Service also reading from a Pricing Service. That map tells you the fan-out, the critical path, and where a stall propagates.

Then, grounded in Google SRE SLO methodology [4], set measurable per-service targets before generating any load:

Service	Latency Target (p99)	Throughput	Error Rate
Cart Service	< 150ms	2,000 req/s	< 0.5%
Inventory Service	< 100ms	3,000 req/s	< 0.1%
Payment Service	< 250ms	1,000 req/s	< 0.1%

These targets become your pass/fail gates. Without them, a load test produces numbers nobody can act on.

Multi-Protocol Load Testing: HTTP, gRPC, WebSockets, and Async Messaging

This is where most tooling falls down. A real microservices stack mixes HTTP/REST at the edge, gRPC between internal services, WebSockets for real-time features, and Kafka or AMQP for event flows. Test only HTTP and you’ve validated maybe a third of your system. Effective coverage means generating realistic load across all of them.

Protocol	Common Tooling Gap	Enterprise Coverage
HTTP/REST	Universally supported	✓
gRPC	Limited in many open-source frameworks	✓
WebSockets	Partial in some SaaS platforms	✓
AMQP / Kafka	Rare in legacy enterprise suites	✓

This breadth is precisely where a platform supporting 150+ protocols earns its place – RadView’s platform lets you script HTTP, gRPC, GraphQL, WebSockets, AMQP, and Kafka load from one place with distributed load generation that mirrors your actual deployment topology. A gRPC load test, for instance, replays parameterized Protobuf messages against the service stub while ramping virtual users, asserting the same p99 target you set in your SLO table. For Kafka, you load a producer at a target message rate and watch consumer lag as the back-pressure signal.

Isolation vs. End-to-End Testing and Dependency Mocking

Use both strategies, deliberately. Isolated testing pins down a single service’s true ceiling: load the Payment Service directly while mocking its downstream bank gateway with a stub that returns a fixed 80ms response. Now any latency you measure is the Payment Service’s own, not the gateway’s – you’ve isolated the variable. End-to-end testing validates the real interaction effects: drive a full Cart → Inventory → Payment user journey across three live services at 5,000 concurrent users, which is the only way to surface latency amplification and cascade behavior. Isolation tells you where a bottleneck is; end-to-end tells you what happens when bottlenecks compound.

Integrating Performance Gates into CI/CD

Make resilience continuous by wiring automated gates into the pipeline. A concrete gate rule: fail the build if p95 latency regresses more than 10% versus the rolling baseline, or if error rate exceeds 0.5%. Add contract tests so an API change can’t silently break a consumer, and a canary stage that runs a scaled-down load test against the new version before full rollout. As detailed in our guide to integrating performance testing into CI/CD pipelines, RadView’s CI/CD integration lets these performance gates run on every service deployment, so a regression is caught in the pipeline rather than in production. The pipeline config invokes the load test as a build step, parses the result against the gate thresholds, and blocks promotion on failure.

Using Distributed Tracing as a Testing Diagnostic, Not Just Monitoring

Tracing is usually framed as production monitoring. Its higher-value use is as a testing diagnostic: run a load test, capture traces, and read exactly which span is the bottleneck or the failing hop in a cascade. Older articles fixate on Jaeger and Zipkin; the modern, vendor-neutral standard is OpenTelemetry, which gives you instrumentation that works across backends [11].

How Trace IDs and Spans Reveal the Failing Hop

The trace lifecycle is concrete. A request enters at the edge and gets assigned a unique trace ID. As it calls downstream services, that ID is injected into the request headers – OpenTelemetry’s context propagation handles this automatically so the ID rides along to every service [11]. Each service records a span (its own slice of the work, with timing) tagged with the trace ID, and exports it to a backend like Jaeger, which assembles all spans sharing that ID into a single waterfall.

Reading that waterfall during a load test is where the diagnosis happens. Picture a 600ms checkout request: the trace shows the API Gateway span at 20ms, Cart at 40ms, Inventory at 30ms – and then a Payment span at 420ms dominating the whole request, with 350ms of that inside a single database call. You’ve isolated the failing hop in seconds, with evidence, instead of guessing. Netflix has used this exact approach with Zipkin to visualize request paths and track latencies across services at scale [12].

Where AI Anomaly Detection Adds Value (and Where Humans Still Decide)

At enterprise scale a single load test produces thousands of trace and metric streams – no human reads all of them. Here’s a concrete capability available today: AI anomaly detection automatically flags a latency anomaly that’s correlated across, say, 30 spans pointing back to one upstream dependency, surfacing a distributed pattern an analyst scanning dashboards would likely miss. RadView’s AI anomaly detection does exactly this kind of cross-stream correlation during load runs.

The honest limit: AI flags the anomaly, but it can’t tell you whether a 15% latency rise is an acceptable trade-off for a new feature or a release-blocking regression. That judgment – weighing business context against the metric – stays human. The roadmap direction is tighter correlation between anomaly flags and probable root-cause spans, but the guardrail holds: AI removes the toil of finding the needle, engineers decide what the needle means.

Real-World Microservices Testing Scenarios

E-Commerce: Cart, Inventory, Payment, and Shipping Under Peak Load

A flash sale is a cascade-and-fan-out stress test in disguise. Set the load target at 10,000 concurrent users hitting the Cart → Inventory → Payment → Shipping chain, with a payment-service SLO of p99 < 250ms. The behavior you’re validating is cascade containment: when Inventory slows under the spike, your circuit breaker and timeout strategy should let Cart degrade gracefully – showing “checking availability” rather than hanging – so a single slow service can’t collapse checkout. For a fuller treatment of preparing for peak shopping events, see our guide to e-commerce application testing. Run it with fault injection adding latency to Inventory and confirm the cascade-containment logic holds at peak concurrency.

Event-Driven & Compliance-Heavy Systems: Financial Services and Healthcare

An event-driven financial system running on async messaging faces its sharpest risk during recovery, where retry storms form. Load the message bus and watch Kafka consumer lag as your back-pressure signal – if lag climbs past, say, 10,000 messages and keeps growing under synchronized producer retries, you’ve found the storm; the fix is jittered backoff and a retry budget, validated by re-running the test with jitter enabled and confirming lag stabilizes [7].

Healthcare FHIR-API microservices carry strict compliance and latency requirements – a patient-record FHIR endpoint might need a p99 under 200ms to meet clinical-workflow SLAs. These systems mix HTTP/REST FHIR APIs with internal async flows, so testing both protocol types in one run matters. Across both contexts, multi-protocol coverage is what lets you load the async bus and the synchronous APIs in a single, coherent test rather than stitching together separate tools.

Frequently Asked Questions

What are microservices in simple terms, and what’s the difference from a monolith?

Microservices structure an application as a set of small, independently deployable services that talk over the network, versus a monolith where everything runs in one process [1]. The practical performance distinction: a monolith fails as a single point – one crash takes the whole app – while microservices isolate failure to a service unless it cascades across dependencies. Independent deployability is the headline benefit; cascading failure is the headline new risk.

How do you performance test microservices, and what protocols and tools are involved?

Three pillars: map service dependencies, define measurable per-service SLOs, and simulate realistic multi-protocol traffic integrated into CI/CD. The protocols that matter span HTTP/REST, gRPC, WebSockets, and messaging (AMQP/Kafka) – HTTP-only testing covers a fraction of a real stack. An enterprise platform with broad protocol support, such as WebLOAD with its 150+ protocols, lets you generate all of those from one place rather than juggling separate tools.

Is testing microservices in isolation enough, or do I always need end-to-end tests?

Isolation alone is a trap. Isolated tests with mocked dependencies tell you a single service’s true ceiling, but latency amplification and cascading failures only appear when services interact under concurrency. You need both: isolation to locate a bottleneck, end-to-end to see what happens when bottlenecks compound across the call graph. Skipping end-to-end is how teams ship systems that pass every component test and still collapse on launch day.

Why do my microservices pass functional tests but fail under real traffic?

Because the three signature failure modes – cascading failures, latency amplification, and retry storms – are concurrency phenomena. A functional test fires one or two requests and sees green; it never creates the positive feedback loop, the parallel fan-out, or the synchronized retry burst that triggers collapse. Per the p99 fan-out math, a per-server 1-second p99 across 100 parallel calls makes 63% of requests slow [6] – invisible at low traffic, catastrophic at scale.

Should I add jitter or remove retries to stop retry storms?

Neither extreme. Removing retries sacrifices legitimate resilience; the fix is jittered backoff plus a retry budget. AWS’s reproducible simulator cut call volume by more than half with 100 contending clients simply by adding full jitter [7], and a server-wide retry budget capping retries at ~10% of request volume prevents the amplification from forming [4]. Test it by simulating synchronized retries under load – the only way to confirm the storm can’t build.

Benchmark numbers, SLO targets, and test results shown in this guide are illustrative of specific test environments and configurations. Reproduce them against your own architecture, traffic patterns, and infrastructure before treating any figure as a baseline.

References

1. Fowler, M. (N.D.). Microservices and MonolithFirst. martinfowler.com. Retrieved from https://martinfowler.com/articles/microservices.html
2. gRPC Authors. (N.D.). Introduction to gRPC. gRPC.io Official Documentation. Retrieved from https://grpc.io/docs/what-is-grpc/introduction/
3. Amazon Web Services. (N.D.). The Difference Between Monolithic and Microservices Architecture. AWS. Retrieved from https://aws.amazon.com/compare/the-difference-between-monolithic-and-microservices-architecture/
4. Ulrich, M. (2017). Addressing Cascading Failures (Chapter 22). In Site Reliability Engineering. Google / O’Reilly Media. Retrieved from https://sre.google/sre-book/addressing-cascading-failures/
5. HdM Stuttgart Computer Science Blog. (2022). Cascading Failures in Large-Scale Distributed Systems. Retrieved from https://blog.mi.hdm-stuttgart.de/index.php/2022/03/03/cascading-failures-in-large-scale-distributed-systems/
6. Dean, J., & Barroso, L. A. (2013). The Tail at Scale. Communications of the ACM, 56(2). doi:10.1145/2408776.2408794. Retrieved from https://www.barroso.org/publications/TheTailAtScale.pdf
7. Brooker, M. (2015, updated 2023). Exponential Backoff and Jitter. AWS Architecture Blog / Amazon Builders’ Library. Retrieved from https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/
8. Fowler, M. (N.D.). CircuitBreaker. martinfowler.com. Retrieved from https://martinfowler.com/bliki/CircuitBreaker.html
9. Principles of Chaos Engineering. (N.D.). Retrieved from https://principlesofchaos.org/
10. Tricentis ShiftSync Community. (N.D.). Testing and Monitoring the Performance of Microservices. Retrieved from https://shiftsync.tricentis.com/software-testing-blogs-69/testing-and-monitoring-the-performance-of-microservices-483
11. OpenTelemetry / CNCF. (N.D.). Observability Primer. Retrieved from https://opentelemetry.io/docs/concepts/observability-primer/
12. GeeksforGeeks. (N.D.). Distributed Tracing in Microservices, referencing Netflix’s use of Zipkin. Retrieved from https://www.geeksforgeeks.org/system-design/distributed-tracing-in-microservices/