30 Claude Prompts for Backend Developers

You are a senior backend engineer specializing in database performance. <context> I wrote a function that loads a parent object along with related records and I am worried it issues one query per related record instead of a batch. </context> <inputs> - Code: [PASTE THE FUNCTION OR METHOD] - ORM or query layer used: [NAME, , SQLALCHEMY, ACTIVERECORD, RAW SQL] - Approximate size of the related collection: [TYPICAL COUNT, WORST CASE COUNT] - Call frequency: [HOW OFTEN THIS PATH RUNS,] - Target route or job name: [ROUTE OR JOB NAME] </inputs> <task> Identify every place the code issues a query inside a loop or inside a per-item callback, and rewrite it to use a single batched query or a join, in the same ORM or SQL style shown. </task> <constraints> Do not just say "use eager loading", show the actual corrected code. If the fix changes what data is fetched, such as loading fields that were not selected before, call that out explicitly. Preserve existing error handling in the rewrite. </constraints> <format> First the list of N plus 1 spots found with a line reference, then the corrected code block, then one sentence on the expected query count reduction, for example twenty queries collapsed to two. </format>

You are a senior backend engineer who tunes database performance for a living. <context> A specific query has gotten slow as the table has grown and I need an index plan, not just a general tip to add an index. </context> <inputs> - The slow query: [PASTE THE SQL OR ORM QUERY] - Table sizes involved: [ROW COUNTS FOR EACH TABLE IN THE QUERY] - Current indexes: [PASTE THE SCHEMAS INDEX DEFINITIONS] - Database engine: [POSTGRES, MYSQL, ETC] - Write volume on the table: [INSERTS OR UPDATES PER MINUTE, ROUGHLY] </inputs> <task> Propose the specific index or indexes to add, including column order for any composite index, and explain why that column order matches the query's filter and sort clauses. State the write cost tradeoff given the write volume provided. </task> <constraints> Do not propose an index on every filtered column independently if a single composite index would serve the query better. If an existing index already covers part of the query, say so instead of duplicating it. Give the exact CREATE INDEX statement. </constraints> <format> The CREATE INDEX statement, then a short explanation of why the column order was chosen, then one paragraph on the write cost given the stated write volume, then how to verify the fix with EXPLAIN. </format>

You are a senior backend engineer who values a clean separation between business logic and persistence. <context> My business logic currently calls the ORM directly and I want a repository interface between them so the persistence layer can be swapped or mocked in tests. </context> <inputs> - Entity: [ENTITY NAME AND ITS FIELDS] - Current ORM calls in the business logic: [PASTE THE RELEVANT CALLS] - Query patterns needed: [LIST THE ACTUAL LOOKUPS, , FIND ACTIVE ONES] - Language and ORM: [LANGUAGE AND ORM NAME] </inputs> <task> Define a repository interface with method signatures that cover exactly the query patterns listed, no speculative extras, and show a concrete implementation of that interface against the stated ORM. </task> <constraints> Method names must describe intent, such as findActiveByEmail, not leak ORM concepts like findByWhereClause. Do not add generic methods like a raw query passthrough, since that defeats the point of the abstraction. Keep the interface to the query patterns actually listed. </constraints> <format> The interface definition first, then the concrete implementation, then a two or three line example of a unit test using a fake implementation of the interface. </format>

You are a senior backend engineer who has run schema migrations against tables that could not tolerate downtime. <context> I need to change a column's type or constraint on a table that is actively read and written in production, and a naive migration would lock the table or break running code. </context> <inputs> - Table and column: [TABLE NAME, COLUMN NAME] - Current type or constraint: [CURRENT DEFINITION] - Target type or constraint: [TARGET DEFINITION] - Approximate row count: [ROW COUNT] - Database engine: [POSTGRES, MYSQL, ETC] - Deployment model: [CAN THE APP CODE DEPLOY BEFORE THE MIGRATION RUNS, YES OR NO] </inputs> <task> Produce a multi-step migration plan that keeps old and new code compatible at every step, such as adding the new column nullable first, backfilling in batches, then switching reads, then dropping the old column. State which steps require a code deploy and which are pure database operations. </task> <constraints> Assume the table cannot be locked for more than a few seconds. Batch any backfill instead of a single UPDATE across the whole table. Call out the exact point where it becomes safe to drop the old column and why. </constraints> <format> A numbered list of steps, each tagged as CODE DEPLOY or DATABASE OPERATION, with the exact SQL for each database operation step. </format>

You are a senior backend engineer experienced with caching in production systems. <context> An endpoint is read heavy and I want to add caching, but I am unsure whether to cache at the database, application, or CDN layer, and how to keep the cache from serving stale data after a write. </context> <inputs> - Endpoint and what it returns: [ENDPOINT DESCRIPTION] - Read to write ratio: [ROUGH RATIO,] - Staleness tolerance: [HOW OLD CAN THE DATA BE, , 1 MINUTE] - Data source: [SINGLE DATABASE, MULTIPLE SERVICES] - Existing infrastructure: [REDIS AVAILABLE, CDN IN FRONT, NEITHER] </inputs> <task> Recommend a caching layer and invalidation strategy that fits the stated staleness tolerance and existing infrastructure, and specify the exact cache key shape and TTL. Address how a write to the underlying data gets reflected, whether by invalidation, a short TTL, or a write-through update. </task> <constraints> Do not recommend a cache-aside pattern with no invalidation path if the staleness tolerance is under a few seconds, be explicit that a low tolerance requires invalidation on write, not just a TTL. Name the specific failure mode of the rejected alternative. </constraints> <format> A recommendation with the cache key format and TTL, then how invalidation works step by step on a write, then one paragraph on what happens to correctness if the cache layer goes down entirely. </format>

You are a senior backend engineer who has cleaned up a service where every error was a generic 500. <context> My service currently throws generic exceptions that all surface as a 500 to callers, and I want a proper error taxonomy so clients can distinguish retryable from non-retryable failures. </context> <inputs> - Service type: [REST API, GRPC SERVICE, MESSAGE CONSUMER] - Common failure sources: [LIST, , DOWNSTREAM TIMEOUT, NOT FOUND, CONFLICT] - Language: [LANGUAGE OR FRAMEWORK] - Current error handling: [PASTE A REPRESENTATIVE CATCH BLOCK OR ERROR HANDLER] </inputs> <task> Define an error taxonomy with a small set of error categories, the HTTP status or equivalent each maps to, and whether each category is safe for a client to retry automatically. Rewrite the current error handler to raise these typed errors instead of the generic exception. </task> <constraints> Keep the taxonomy to the categories that actually occur in this service, do not invent categories with no failure source listed. Every category must state explicitly whether it is retryable, do not leave it implied. Preserve any logging currently in the handler. </constraints> <format> A table of category, status code, retryable yes or no, and example cause, followed by the rewritten error handler code. </format>

You are a senior backend engineer who has been paged for retry storms that made an outage worse. <context> My service calls a downstream dependency that sometimes fails transiently, and the current code either does not retry at all or retries in a way I am not confident is safe. </context> <inputs> - Downstream call code: [PASTE THE FUNCTION MAKING THE CALL] - Failure modes observed: [TIMEOUT, 5XX, CONNECTION RESET, RATE LIMIT RESPONSE] - Is the operation idempotent: [YES, NO, UNSURE] - Downstream's stated rate limit or capacity: [LIMIT IF KNOWN, OR NONE] - Caller's own latency budget: [MAX ACCEPTABLE TOTAL LATENCY] </inputs> <task> Add a retry policy with exponential backoff and jitter, bounded by the stated latency budget, that only retries the failure modes that are safe to retry given the idempotency answer. If the operation is not idempotent, explain what has to change before retries are safe at all. </task> <constraints> Do not retry on failure modes that indicate the request already succeeded server side unless idempotency is confirmed. Cap total retry attempts and total elapsed time explicitly rather than leaving it open ended. Include jitter, not fixed interval backoff. </constraints> <format> The rewritten code with the retry policy applied, then a short table of failure mode versus retry decision, then one paragraph on how this interacts with the downstream's rate limit if one was given. </format>

You are a senior backend engineer experienced with resilience patterns in distributed systems. <context> A downstream dependency my service calls has become unreliable and I want to stop hammering it during an outage instead of letting every request pile up waiting on it. </context> <inputs> - Call site code: [PASTE THE FUNCTION OR CLASS MAKING THE CALL] - Current timeout setting: [TIMEOUT VALUE OR NONE] - Traffic volume to this call: [REQUESTS PER SECOND] - What should happen when the breaker is open: [FALLBACK VALUE, CACHED RESPONSE, OR FAIL THE REQUEST] - Language or framework: [LANGUAGE OR FRAMEWORK, INCLUDING ANY EXISTING CIRCUIT BREAKER LIBRARY] </inputs> <task> Add a circuit breaker around the call with a specific failure threshold and reset timeout, wired to the stated fallback behavior when open. If no timeout is currently set on the call itself, add one, since a circuit breaker without a timeout on the underlying call does not actually bound latency. </task> <constraints> State the exact threshold values chosen and why they fit the stated traffic volume, do not leave them as placeholders. Make the half-open recovery behavior explicit, not just open and closed. Keep the fallback behavior consistent with what was specified. </constraints> <format> The modified code with the circuit breaker applied, then a short explanation of the threshold and reset timeout chosen, then one sentence on what a caller sees during the open state. </format>

You are a senior backend engineer doing incident response. <context> A service threw an error in production and I have the stack trace and surrounding log lines but have not found the root cause yet. </context> <inputs> - Stack trace: [PASTE THE FULL STACK TRACE] - Surrounding log lines: [PASTE A FEW LINES BEFORE AND AFTER] - Recent changes: [ANY RECENT DEPLOY, CONFIG CHANGE, OR TRAFFIC SPIKE] - Frequency: [HAPPENED ONCE, INTERMITTENT, OR CONSTANT SINCE A SPECIFIC TIME] </inputs> <task> Propose the most likely root cause given the stack trace and context, and rank two or three alternative hypotheses if the top one is not confirmed. For each hypothesis, state the specific piece of evidence in the logs that supports or would rule it out. </task> <constraints> Do not propose a hypothesis the stack trace contradicts. If the trace and logs are insufficient to narrow it down, say what additional log line or metric would resolve the ambiguity instead of guessing. </constraints> <format> A ranked list of hypotheses, each with a one line piece of supporting evidence and a one line way to confirm or rule it out, then a short list of any additional data needed if the evidence given is insufficient. </format>

You are a senior backend engineer doing a focused code review pass on error handling only. <context> I want a review pass specifically looking for places where an exception is caught but the failure is hidden, logged without context, or silently converted into a success response. </context> <inputs> - Code: [PASTE THE FILE OR FUNCTIONS TO REVIEW] - Language: [LANGUAGE] - What callers currently see on failure: [DESCRIBE CURRENT BEHAVIOR IF KNOWN] </inputs> <task> Find every catch block, rescue clause, or error branch that swallows an error, logs it without enough context to debug later, or returns a success status despite a failure occurring. For each one, show the corrected version. </task> <constraints> Do not flag a broad catch that legitimately re-raises or propagates the error, only flag ones that stop the error from surfacing. Each corrected version must include enough context in the log line to identify the failing input, not just the exception message. Preserve existing behavior for the success path. </constraints> <format> A numbered list of findings with a line reference, the problem in one sentence, and the corrected code snippet for each. </format>

You are a senior backend engineer who has fixed duplicate charge bugs in a payments system. <context> An endpoint that creates a financial or otherwise non-repeatable side effect can currently be called twice with the same intent, for example from a client retry or a double click, and I need it to be safe to call more than once. </context> <inputs> - Endpoint code: [PASTE THE HANDLER FUNCTION] - Side effect performed: [WHAT IT CREATES OR CHARGES] - Existing unique identifiers available: [ORDER ID, USER ID, CLIENT REQUEST ID IF SENT] - Storage available: [DATABASE TYPE, WHETHER REDIS IS AVAILABLE] </inputs> <task> Add idempotency using an idempotency key, either supplied by the client or derived from existing request data if none is sent, and show how the key is stored, checked, and what happens on a second call with the same key, including how the second call gets the same response as the first. </task> <constraints> Do not merely deduplicate at the database unique constraint level if the operation involves an external side effect like a payment charge, the key check must happen before the side effect fires. State how long the idempotency key is retained and why that window is enough. </constraints> <format> The rewritten handler code, then a short explanation of what the second call with the same key returns, then one sentence on the retention window chosen for the key. </format>

You are a senior backend engineer who diagnoses concurrency bugs. <context> I have code that reads a value, modifies it, and writes it back, and under concurrent requests the final value sometimes ends up wrong, which looks like a lost update. </context> <inputs> - Code: [PASTE THE READ MODIFY WRITE FUNCTION] - Storage: [DATABASE TYPE, , MYSQL, DYNAMODB] - Concurrency level: [ROUGH NUMBER OF CONCURRENT CALLERS THAT CAN HIT THIS] - Consistency requirement: [MUST BE EXACT, OR EVENTUAL IS ACCEPTABLE] </inputs> <task> Identify the exact race window in the code and fix it using an approach appropriate to the storage engine, such as an atomic update, optimistic concurrency with a version column, or a row level lock, and explain why that approach fits the stated concurrency level and consistency requirement better than the alternatives. </task> <constraints> Do not fix it by simply adding an application level in-memory lock if multiple processes or instances can run this code, that does not close the race across processes. State what the corrected code does when it detects a conflicting concurrent write, such as retry or fail. </constraints> <format> The corrected code, then one paragraph explaining the exact race window that existed before, then one sentence on the conflict behavior in the fixed version. </format>

You are a senior backend engineer who has run scheduled jobs across multiple instances of a service. <context> A scheduled job runs on every instance of my service but should only actually execute once per interval, and right now it either runs multiple times or has no coordination at all. </context> <inputs> - Job description: [WHAT THE JOB DOES] - Run interval: [HOW OFTEN IT SHOULD RUN] - Typical job duration: [HOW LONG ONE RUN TAKES] - Infrastructure available: [REDIS, POSTGRES ADVISORY LOCKS, DYNAMODB, ETC] - Number of instances: [HOW MANY INSTANCES RUN THIS CODE] </inputs> <task> Design a distributed lock so only one instance executes the job per interval, using the infrastructure available, and specify the lock's expiry time relative to the typical job duration so a crashed holder does not block all future runs forever. </task> <constraints> The lock expiry must exceed the typical job duration with margin, state the exact value and the margin reasoning. Address what happens if the job is still running when its lock expires, since that is the case most naive implementations get wrong. </constraints> <format> The locking code for the acquire and release steps, then the chosen expiry value with the margin reasoning, then one paragraph on the long-running-job edge case. </format>

You are a senior backend engineer who has cleaned up batch jobs that left data half updated after a crash. <context> I have a batch job that processes many records in one run, and if it fails partway through I am not confident about what state it leaves things in or whether rerunning it is safe. </context> <inputs> - Job code: [PASTE THE BATCH PROCESSING FUNCTION] - What each record processing step does: [DESCRIBE THE SIDE EFFECT PER RECORD] - Current failure behavior: [STOPS ENTIRELY, SKIPS AND CONTINUES, UNKNOWN] - Is the per record operation idempotent: [YES, NO, UNSURE] </inputs> <task> Review whether the job can be safely rerun from the start after a partial failure, and if not, add tracking of which records were already processed so a rerun only touches the remaining ones. Recommend whether failures should stop the whole batch or skip and continue, based on the side effect described. </task> <constraints> Do not assume rerunning from the start is safe just because most operations look similar to an upsert, check the actual side effect described. If the per record operation is not idempotent, the fix must include a way to track completed records, not just a suggestion to be careful. </constraints> <format> A verdict on rerun safety in the current form, then the modified code with progress tracking added, then one sentence recommending stop versus skip and continue with the reasoning. </format>

You are a senior backend engineer who builds message queue consumers. <context> My service consumes messages from a queue and the queue's delivery guarantee means the same message can arrive more than once, but my processing logic currently assumes each message arrives exactly once. </context> <inputs> - Consumer code: [PASTE THE MESSAGE HANDLER] - Queue system: [SQS, KAFKA, RABBITMQ, ETC] - Delivery guarantee: [AT LEAST ONCE, UNKNOWN] - Side effect per message: [WHAT PROCESSING A MESSAGE DOES] - Storage available for dedup tracking: [DATABASE, REDIS, ETC] </inputs> <task> Add deduplication so a redelivered message with the same identifier does not repeat its side effect, using a dedup store appropriate to the storage available, and handle the case where the message has no natural unique identifier by deriving one from its content. </task> <constraints> State the retention window for the dedup record and why it covers the queue's maximum redelivery window. Do not rely on the queue's own deduplication feature alone if the queue system does not guarantee exactly once, since most do not. </constraints> <format> The modified consumer code with dedup checking added, then one sentence on the retention window chosen, then one sentence on how a message with no natural identifier is deduplicated. </format>

You are a senior backend engineer who has been paged for timeouts caused by slow work left in the request path. <context> A request handler currently does a piece of work inline and I am not sure whether it should stay synchronous or move to a background job. </context> <inputs> - The work in question: [DESCRIBE WHAT THE CODE DOES] - Current typical duration: [HOW LONG IT TAKES NOW] - Does the caller need the result immediately: [YES, NO, PARTIALLY] - Failure tolerance: [CAN THIS SILENTLY FAIL AND RETRY LATER, OR MUST THE USER KNOW IMMEDIATELY] - Job infrastructure available: [QUEUE SYSTEM NAME, OR NONE] </inputs> <task> Recommend synchronous or asynchronous, and if asynchronous, describe how the caller finds out the result, such as polling, a webhook, or a follow up notification. If no job infrastructure exists yet, name the smallest viable option given the stated scale rather than defaulting to a full queue system. </task> <constraints> Do not recommend background processing just because the work is slow, if the caller needs the result immediately and cannot tolerate a delay, say so and address the slowness a different way instead. Be concrete about how the caller learns the outcome, do not leave that vague. </constraints> <format> A recommendation in one sentence, then a paragraph of reasoning tied to the caller need and failure tolerance given, then a concrete description of the result delivery mechanism if async. </format>

You are a senior backend engineer who has cleaned up a queue where failing jobs retried forever and blocked everything behind them. <context> A specific job type in my background processing system fails for some inputs and currently either retries indefinitely or silently disappears, and I need a proper dead letter path. </context> <inputs> - Job processing code: [PASTE THE JOB HANDLER] - Queue or job system: [NAME, , BULLMQ, SQS, CELERY] - Current retry behavior: [DESCRIBE WHAT HAPPENS ON FAILURE TODAY] - What should happen to a permanently failing job: [ALERT, MANUAL REVIEW QUEUE, DISCARD WITH LOG] </inputs> <task> Add a bounded retry count with backoff, and after retries are exhausted, route the job to a dead letter destination that matches what should happen, with enough context captured, such as the original payload and the final error, for someone to diagnose it later without re-running the job blind. </task> <constraints> Cap retries at a specific number and state it, do not leave it unbounded. The dead letter record must include the original input and the last error message, not just a generic failure flag. If alerting is requested, specify what triggers the alert, such as a threshold of dead lettered jobs per hour, not every single one individually if that would be noisy. </constraints> <format> The modified job handler code with retry and dead letter logic, then a short description of what the dead letter record contains, then one sentence on the alerting trigger if applicable. </format>

You are a senior backend engineer who processes large datasets without exhausting memory or hitting job timeouts. <context> I need a job that processes a large number of records, too many to load into memory at once or finish inside a single job execution's time limit. </context> <inputs> - Data source: [TABLE OR SOURCE AND APPROXIMATE ROW COUNT] - Per record work: [WHAT HAPPENS TO EACH RECORD] - Job execution time limit: [TIME LIMIT IF ONE EXISTS,] - Job system: [NAME, , BULLMQ, CELERY, LAMBDA] </inputs> <task> Design a chunked processing approach where the job pulls a bounded batch, processes it, records its progress, and re-enqueues itself or triggers the next chunk, so no single execution risks the stated time limit or high memory use. Include how progress is tracked so a crash mid-run does not lose track of where it left off. </task> <constraints> Choose a specific batch size and justify it against the per record work and the time limit given. Do not design a single unbounded loop that just hopes to finish in time. Progress tracking must survive a crash, not live only in the job's in-memory state. </constraints> <format> The chunked job code, then the chosen batch size with the reasoning tied to the stated time limit, then one sentence on how progress recovers after a crash. </format>

You are a senior backend engineer who has debugged a background pipeline with no visibility into where jobs were stuck. <context> My background job pipeline works most of the time but when something goes wrong I cannot easily tell how many jobs are queued, how many are failing, or how far behind processing is. </context> <inputs> - Job system: [NAME, , BULLMQ, SQS, CELERY] - Pipeline stages: [LIST THE STAGES A JOB PASSES THROUGH] - Monitoring tool available: [DATADOG, PROMETHEUS, CLOUDWATCH, OR NONE] - Current visibility: [WHAT YOU CAN SEE TODAY, IF ANYTHING] </inputs> <task> Recommend the specific metrics to emit at each pipeline stage, such as queue depth, processing latency, and failure count, and show example instrumentation code using the monitoring tool available. Recommend one or two alert thresholds tied to those metrics that would have caught a pipeline falling behind before it became a customer facing problem. </task> <constraints> Do not recommend a generic dashboard, tie each recommended metric to a specific stage in the pipeline described. Alert thresholds must be concrete numbers or rates, not vague guidance like "alert if it seems slow". </constraints> <format> A table of pipeline stage, metric, and why it matters, then the instrumentation code for one representative stage, then two alert threshold recommendations with the reasoning. </format>

You are a senior backend engineer who has migrated synchronous call chains to event driven architectures. <context> A workflow today is a chain of synchronous calls between services, and I want to evaluate moving part of it to an event driven model using events or messages instead of direct calls. </context> <inputs> - Current call chain: [DESCRIBE THE SEQUENCE OF SYNCHRONOUS CALLS] - Which step is the candidate for going async: [THE SPECIFIC STEP] - Consumers of that step's result: [WHO NEEDS TO KNOW WHEN IT COMPLETES] - Ordering requirement: [MUST EVENTS BE PROCESSED IN ORDER, OR NOT] - Existing messaging infrastructure: [NAME IF ANY, OR NONE] </inputs> <task> Describe the event driven version of the identified step: what event gets published, its payload, who subscribes, and how the original caller finds out the eventual outcome if it still needs to. Address the ordering requirement explicitly in the design. </task> <constraints> Do not propose this migration if the caller needs the result before it can proceed and there is no plan for how it waits or gets notified, call that out as a blocker instead of hand-waving it. If ordering matters and the messaging infrastructure does not guarantee it, say what has to change. </constraints> <format> The event payload shape, the publisher and subscriber roles, one paragraph on how the original caller learns the outcome, and one paragraph addressing the ordering requirement. </format>

You are a senior backend engineer who writes runbooks that on-call engineers actually use at 3am. <context> An alert fires periodically in production and right now whoever is on call has to figure out the response from scratch each time. </context> <inputs> - Alert name and trigger condition: [WHAT THE ALERT IS AND WHAT TRIGGERS IT] - Known causes so far: [LIST WHATEVER CAUSES HAVE BEEN FOUND IN PAST INCIDENTS] - Available dashboards or logs: [WHERE TO LOOK] - Safe mitigations: [WHAT AN ON CALL ENGINEER CAN SAFELY DO WITHOUT ESCALATING] </inputs> <task> Write a runbook: what the alert means in plain language, the first three things to check in order, the known causes with how to confirm each one, and the safe mitigation steps for each cause. State clearly when to escalate instead of continuing to investigate alone. </task> <constraints> Order the checks from fastest to confirm to slowest, do not list them in an arbitrary order. Do not include a mitigation step that requires access or approval the on-call engineer would not have at 3am. Keep each step actionable, not descriptive. </constraints> <format> Sections: What this alert means, First checks in order, Known causes and how to confirm, Mitigations, When to escalate. </format>

You are a senior backend engineer who reviews deploys for whether they can be safely rolled back. <context> I am about to ship a change and want to know before deploying whether a rollback would actually work cleanly if something goes wrong. </context> <inputs> - Change summary: [WHAT THE DEPLOY CHANGES, CODE, SCHEMA, CONFIG] - Schema changes included: [LIST ANY, OR NONE] - Feature flag usage: [IS THE NEW BEHAVIOR BEHIND A FLAG, YES OR NO] - Order of operations: [WHAT DEPLOYS OR RUNS FIRST, , OR TOGETHER] </inputs> <task> Assess whether rolling back the code deploy alone, without reversing the schema change, would leave the system in a broken or inconsistent state. If schema and code are coupled such that rollback is not clean, say exactly what breaks and propose the sequencing that would make rollback safe. </task> <constraints> Do not conclude a deploy is rollback safe just because a feature flag exists, check whether the flag actually gates every new code path including schema reads and writes. Be specific about what breaks, not a generic warning that migrations are risky. </constraints> <format> A verdict of rollback safe or not, then the specific reason tied to the schema and ordering details given, then a revised sequencing plan if the current one is unsafe. </format>

You are a senior backend engineer who has seen health checks that reported healthy while the service was actually broken. <context> My service has a health check endpoint but it just returns 200 unconditionally, so it does not actually detect the failures that matter, like a lost database connection. </context> <inputs> - Service dependencies: [LIST DEPENDENCIES, , CACHE, DOWNSTREAM API] - How the health check is used: [LOAD BALANCER, KUBERNETES LIVENESS, KUBERNETES READINESS, UPTIME MONITOR] - Acceptable check latency: [HOW LONG THE CHECK CAN TAKE] - Current endpoint code: [PASTE IT IF IT EXISTS] </inputs> <task> Design a health check that actually verifies the dependencies that matter for the stated usage, distinguishing liveness from readiness if both are relevant, and returns different responses for a fully healthy state versus a degraded but still serving state. Keep the check within the stated latency budget. </task> <constraints> Do not check every dependency synchronously on every request if that would exceed the latency budget, use a cached or periodic check instead and say so explicitly. If used as a Kubernetes liveness probe, do not include checks that would cause a working pod to be killed for a transient downstream issue, that belongs in readiness instead. </constraints> <format> The health check endpoint code, then a short explanation of what liveness versus readiness each check, then one sentence on how the check stays within the latency budget. </format>

You are a senior backend engineer who diagnoses memory growth in long running processes. <context> A long running service's memory usage climbs steadily until it gets restarted, and I need to narrow down where the leak is likely coming from before profiling. </context> <inputs> - Language and runtime: [LANGUAGE, RUNTIME VERSION] - Memory growth pattern: [STEADY CLIMB, STEP INCREASES, CORRELATED WITH SPECIFIC TRAFFIC] - Suspect code areas: [ANY CACHES, EVENT LISTENERS, CONNECTION POOLS, OR BACKGROUND TIMERS IN THE SERVICE] - Relevant code: [PASTE THE SUSPECT CODE IF KNOWN] </inputs> <task> Given the growth pattern and suspect areas, rank the most likely causes, such as an unbounded cache, a listener that is added but never removed, or a connection pool that leaks connections under a specific error path. For the top hypothesis, point to the specific line or pattern in the code that supports it if code was provided. </task> <constraints> Do not default to "take a heap snapshot" as the entire answer, that is a next step, not a diagnosis. Tie each hypothesis to the specific growth pattern described, a steady climb and step increases point to different causes. </constraints> <format> A ranked list of hypotheses with the reasoning tied to the growth pattern, then for the top hypothesis a specific code reference if code was given, then one concrete next step to confirm it, such as a specific metric or heap diff to capture. </format>

You are a senior backend engineer who plans load tests before high traffic launches. <context> A new endpoint is about to launch to real traffic and I want a load test plan that would actually catch the failure modes likely to show up, not just a generic throughput number. </context> <inputs> - Endpoint and what it does: [ENDPOINT DESCRIPTION] - Expected launch traffic: [REQUESTS PER SECOND AT PEAK] - Dependencies it calls: [DATABASE, CACHE, DOWNSTREAM SERVICES] - Known thin points: [ANYTHING YOU ALREADY SUSPECT WILL STRUGGLE, OR NONE] - Load testing tool available: [NAME, OR NONE] </inputs> <task> Design a load test plan that ramps to the expected peak and beyond, specifically targeting the dependencies and thin points listed, and define the specific metrics that would indicate a failure, such as p99 latency crossing a threshold or error rate crossing a threshold, not just "it feels slow". </task> <constraints> Include a step that tests beyond expected peak, not just at it, since launches often exceed forecasts. Name the exact metric thresholds that define pass or fail, do not leave success criteria vague. If a known thin point was listed, make sure the plan specifically exercises it rather than only testing the happy path. </constraints> <format> A numbered load test plan with traffic ramp steps, then a table of metric and pass or fail threshold, then one paragraph on how the known thin point is specifically exercised. </format>