Cheat Sheets

Three dense quick references by persona—HTTP and Spring annotations for developers, decision trees for tech leads, and platform comparisons for architects. Use Copy sheet for plain text, persona filters to focus one role, or print (Cmd/Ctrl+P).

developer lead architect

Developer Cheat Sheet

REST semantics, Spring Cloud wiring, Resilience4j annotations, Kafka config. Chapters: Communication, Resilience.

developer

REST API status codes

CodeMeaningWhen to useRetry?
200 OKSuccess with bodyGET, PUT sync update
201 CreatedResource createdPOST create; include Location
204 No ContentSuccess, empty bodyDELETE, PUT no response body
400 Bad RequestClient errorValidation failed, malformed JSONNo
401 UnauthorizedNot authenticatedMissing/invalid tokenNo
403 ForbiddenNot authorizedValid token, insufficient scopeNo
404 Not FoundResource missingUnknown ID (not “wrong method”)No
409 ConflictState conflictDuplicate, version mismatchNo
422 UnprocessableSemantic errorValid JSON, business rule failNo
429 Too Many RequestsRate limitedInclude Retry-AfterYes, after delay
500 Internal ErrorServer bugUnexpected exceptionMaybe
502 Bad GatewayUpstream invalidProxy/gateway upstream failYes
503 Service UnavailableTemporarily downOverload, maintenance, breaker openYes + backoff
504 Gateway TimeoutUpstream timeoutDownstream exceeded deadlineYes
// Problem+JSON error body (RFC 7807)
{
  "type": "https://api.example.com/errors/insufficient-stock",
  "title": "Insufficient stock",
  "status": 409,
  "detail": "SKU-42 has 0 units available",
  "instance": "/orders/req-8f2a"
}

Spring Cloud annotations

Annotation / configModulePurpose
@EnableDiscoveryClientDiscoveryRegister with Eureka / Consul / K8s discovery
@LoadBalancedLoadBalancerRestTemplate/WebClient resolves http://order-service
@FeignClient("order-service")OpenFeignDeclarative HTTP client interface
@EnableFeignClientsOpenFeignScan Feign interfaces on startup
spring.cloud.gateway.routesGatewayRoute predicates, filters, URI targets
TokenRelay filterGatewayForward OAuth2 bearer to downstream
@RefreshScopeConfigRebind beans on config server push
@ConfigurationPropertiesBootType-safe bind from YAML/env
spring.cloud.stream.function.definitionStreamFunctional binding: processOrder;publishEvent
@KafkaListenerKafkaTopic consumer method (Spring Kafka)
@FeignClient(name = "inventory-service", configuration = FeignConfig.class)
public interface InventoryClient {
  @GetMapping("/api/v1/stock/{sku}")
  StockResponse getStock(@PathVariable String sku);
}

@Bean
@LoadBalanced
RestTemplate restTemplate() { return new RestTemplate(); }

Resilience4j annotations

AnnotationStates / behaviorKey YAML keys
@CircuitBreaker(name, fallbackMethod)CLOSED → OPEN → HALF_OPENfailureRateThreshold, waitDurationInOpenState
@Retry(name, fallbackMethod)Re-attempt transient errorsmaxAttempts, waitDuration, exponential backoff
@Bulkhead(name, type)THREADPOOL or SEMAPHOREmaxConcurrentCalls, maxWaitDuration
@TimeLimiter(name)CompletableFuture timeouttimeoutDuration
@RateLimiter(name)Token bucket per periodlimitForPeriod, limitRefreshPeriod
// Decorator order (outer → inner): RateLimiter → CircuitBreaker → Bulkhead → Retry → TimeLimiter → call

@CircuitBreaker(name = "payment", fallbackMethod = "payFallback")
@Retry(name = "payment")
@Bulkhead(name = "payment", type = Bulkhead.Type.SEMAPHORE)
public PaymentResult charge(Order order) { ... }

// application.yml
resilience4j.circuitbreaker:
  instances:
    payment:
      slidingWindowSize: 20
      failureRateThreshold: 50
      waitDurationInOpenState: 30s

Kafka consumer config

PropertyTypical valueNotes
spring.kafka.bootstrap-serversbroker:9092Comma-separated brokers
spring.kafka.consumer.group-idorder-serviceOne group per logical consumer app
auto-offset-resetearliest / latestWhen no committed offset
enable-auto-commitfalsePrefer manual ack after processing
max-poll-records100500Batch size vs processing time
max-poll-interval-ms300000+Must exceed max batch process time
isolation.levelread_committedSkip uncommitted transactional msgs
key/value-deserializerJson / AvroSchema Registry for Avro
@KafkaListener(topics = "order-placed", groupId = "inventory-service")
public void onOrderPlaced(ConsumerRecord<String, OrderPlacedEvent> record, Acknowledgment ack) {
  process(record.value());
  ack.acknowledge();  // after idempotent success
}

Kafka producer config

PropertyTypical valueNotes
acksallWait for ISR replicas (durable)
retries3+With enable.idempotence=true
enable.idempotencetrueExactly-once per producer instance
transactional.idorder-service-txTransactional producer + consume-transform-produce
compression.typelz4 / zstdCPU vs bandwidth trade-off
linger.ms520Batch more records before send
batch.size16384+Bytes per batch target
key/value-serializerJson / AvroMatch consumer + schema version
spring:
  kafka:
    producer:
      acks: all
      properties:
        enable.idempotence: true
        max.in.flight.requests.per.connection: 5
    template:
      default-topic: domain-events

Tech Lead Cheat Sheet

When to pick which pattern, sync vs async, CAP/PACELC, data pattern matrix. See Patterns → Decision helper.

lead

Pattern decision tree

flowchart TD
  START[New integration problem] --> Q1{Migrating monolith?}
  Q1 -->|yes| STR[Strangler Fig plus ACL]
  Q1 -->|no| Q2{Multi-service write?}
  Q2 -->|yes| SAG[Saga plus Outbox]
  Q2 -->|no| Q3{Need instant read-your-writes?}
  Q3 -->|yes| SYNC[Sync REST or gRPC plus Timeout Breaker]
  Q3 -->|no| ASYNC[Events Kafka plus Idempotent consumer]
  SYNC --> Q4{Client-specific API?}
  Q4 -->|yes| BFF[BFF or API Composition]
  Q4 -->|no| DONE[Ship with correlation ID and RED metrics]
ScenarioStart hereAlso consider
Legacy ERP integrationAnti-Corruption LayerStrangler if replacing module
Checkout spans 3 DBsSaga + OutboxNot 2PC
Mobile vs web payloadsBFFNot one fat API
Downstream flakyBreaker + TimeoutFallback for reads
Audit full historyEvent SourcingCQRS read models
Public API abuseRate limit at gatewayAuth + quotas

Sync vs async guide

Choose sync whenChoose async when
User waits for result in same requestTemporal decoupling acceptable
Strong read-your-writes neededEventual consistency OK
Simple query/ command, 1–2 hopsFan-out to many subscribers
Low latency critical path under 200 msAudit trail and replay matter
Failure must surface immediately to userPeak buffering beats sync overload
Sync stackAsync stack
REST / gRPC + WebClientKafka + outbox relay
Timeout + breaker + bulkheadIdempotent consumer + DLQ
Trace context on HTTP headersTrace in Kafka record headers
Max chain depth 3–4 hopsSaga choreography or orchestration
Rule of thumb: if the user did not trigger it and does not wait — async.
If failure blocks the UI — sync with resilience, not fire-and-forget.

CAP theorem cheat

LetterMeaningDuring partition you pick
ConsistencyAll nodes see same dataReject writes/reads → CP
AvailabilityEvery request gets a responseAllow stale reads → AP
PartitionNetwork split between nodesNot optional — must choose C or A
Store / patternTypical CAPPACELC else (no partition)
PostgreSQL single primaryCPLow latency, strong consistency
Cassandra tunableAP defaultLatency vs consistency per query
Redis primary-replicaAP (async repl)Low latency reads
Microservices + eventsAP across servicesEventual consistency by design
2PC / XA across DBsCP but fragileAvoid — use saga
PACELC: If Partition → A or C; Else → Latency or Consistency.
Document per-service in ADR — not one slide for whole platform.

Data pattern selection guide

ProblemPatternAvoid
Service autonomyDB per serviceShared tables
Multi-DB business transactionSaga2PC across services
Reliable event after commitTransactional outboxDual write without outbox
Read scale ≠ write scaleCQRSOne model for everything
Full audit / replayEvent sourcingUpdate-in-place only
One screen, few servicesAPI compositionDeep sync graphs
Cross-service reportRead model / data warehouseCross-service SQL join
Combine: DB per service + outbox + saga + idempotent consumers
is the default production stack for write paths.

Architect Cheat Sheet

Saga vs 2PC, mesh options, observability stacks, deployment strategies. Chapters: Data, Mesh, Observability, Deployment.

architect

Saga vs 2PC decision

Dimension2PC / XASaga
ConsistencyGlobal ACID (theoretical)Eventual + compensations
Availability under partitionBlocking — locks heldEach step commits locally
Failure handlingRollback all participantsCompensating transactions
CouplingTight — all DBs in one txLoose — events/commands
Ops complexityCoordinator SPOF, heuristicsIdempotency, outbox, tracing
Microservices fitPoor — avoidStandard approach
Use 2PC only whenUse saga when
Single modular monolith, one DBMultiple service-owned databases
Regulatory mandate + single vendor XALong-running business processes
Short transactions, same data centerNeed independent deploy per service
Orchestrated saga: central coordinator — easier trace, coupling risk.
Choreographed saga: domain events — decoupled, harder debug.
Both need: outbox, idempotent consumers, explicit compensations.

Service mesh comparison

OptionData planeBest forTrade-off
IstioEnvoy sidecarFull L7 policy, canary, mTLS, multi-clusterYAML surface, resource cost
LinkerdLinkerd2-proxySimple mTLS + metrics, low overheadFewer traffic CRDs
Consul ConnectEnvoyHashiCorp stack, VM + K8sConsul ops dependency
Cilium (mesh mode)eBPFPerformance, K8s-native networkingFeature maturity varies
No meshApp libs + gateway<15 homogeneous Java servicesInconsistent polyglot policy
CapabilityMeshApp (Resilience4j + OTel)
mTLS east-westAutomatic sidecarManual certs or lib
RED metricsL7 without codeMicrometer / actuator
Business spansNoOpenTelemetry in app
Canary traffic splitVirtualService weightsFlagger / Argo Rollouts
Retry policyEnvoy route configResilience4j — pick one layer

Observability stack options

StackMetricsLogsTracesNotes
LGTMMimir/PrometheusLokiTempoGrafana unified; cost-effective at scale
ELK + JaegerElastic APMElasticsearchJaegerRich log search; higher index cost
Datadog / New RelicSaaSSaaSSaaSFast setup; vendor lock-in, cost
Cloud nativeCloudWatch / Azure MonitorSameX-Ray / App InsightsGood if all-in on one cloud
OpenTelemetry hubOTel Collector → anyOTel logsOTel tracesInstrument once, swap backends
SignalAlert on?Store
Metrics (RED, SLO burn)Yes — primary pagingPrometheus / Mimir
TracesVia tail sampling rulesTempo / Jaeger
LogsRare — security anomaliesLoki / Elasticsearch
Correlation IDAll three signals
Minimum viable: Micrometer + Prometheus + Grafana + OTel traces + JSON logs + Loki.
Gate prod on: RED dashboards, one SLO, trace_id in every log line.

Deployment strategy comparison

StrategyTraffic shiftRollback speedCost / complexityBest for
Rolling updateGradual pod replaceRe-roll previous imageLow — K8s defaultStateless, backward-compatible
Blue-greenInstant flipSeconds — switch back2× infra during cutoverCritical paths, schema compatible
Canary1→5→25→100%Auto on SLO regressionMedium — metrics gatesHigh-risk releases
Feature flagsCode deployed darkToggle off instantlyFlag lifecycle debtDecouple deploy from release
GitOpsGit PR → reconcileRevert Git commitMedium — Argo/Flux setupAuditable prod changes
CombineWhy
GitOps + rollingDefault safe baseline
GitOps + canary + SLOAutomated promotion/rollback
Feature flags + any deployKill switch without redeploy
Blue-green + DB migrationsExpand-contract schema phases
Never kubectl set image in prod without Git record.
Canary promotion gates: error rate, p99 latency, business metric (conversion).