Cookie preferences

Essential cookies keep this site working. Optional Google Analytics cookies help us understand page visits and improve the site. You can change your choice anytime. Cookie policy

Skip to content
ForCSGuy System Design Atlas home

Library / Case Studies

Lightweight Distributed Architecture to Handle Thousands of Library Releases at eBay

A new lightweight distributed architecture is proposed and applied on eBay’s release system to support thousands of libraries release work in high efficiency.

IntermediateDistributed SystemsDeployment

By eBay engineers · eBay · Added 2026-10-12

Open original source

All content belongs to eBay engineers / eBay. We only link to it and give credit. Report a problem

Learn this case study

About 37 min left. Your work is saved as you go.

What you are about to study

eBay explains a real system. You should know the basics: caching, queues and replication.

Ideas you will meet

Distributed Systems
Consensus, time, failure and the fundamentals of scale-out.
Deployment
Releases, feature flags, rollbacks and continuous delivery.

What we already know about this

Our own lessons on these ideas. Read them here before you start, so it makes sense.

  • Core Concepts: How Things Actually Work · 8 minDeployment strategiesRolling, blue-green, canary and feature flags: how to release changes with less risk, including database changes.Read here

    Why strategy matters

    Most outages follow a change. A good deployment strategy limits the blast radius and makes rollback fast.

    The main strategies

    Recreate (big bang)

    Stop the old version, start the new one. Simple, but there is downtime and no easy rollback.

    Rolling update

    Replace instances a few at a time. No downtime and little extra capacity, but for a while both versions serve traffic, so they must be compatible. Rollback means rolling back the same way.

    Blue-green

    Run two identical environments. Blue serves live traffic; deploy to green, test it, then switch the router to green. Rollback is flipping back. Cost: double the capacity during the switch, and shared state (databases) still needs care.

    Canary

    Send a small share (1%, 5%, 25%...) of traffic to the new version, watch the metrics, then widen. If errors rise, roll back automatically. Needs good monitoring and traffic splitting.

    Figure SDA-CORE-12-1 · Canary · © forcsguy.com

    Feature flags

    Ship code switched off, and enable it for chosen users (or a percentage) at runtime. It separates deploying from releasing, and gives an instant kill switch. Remove old flags to avoid clutter.

    Figure SDA-CORE-12-2 · Four ways to put a new version live · © forcsguy.com

    Before: release to everyone at once

    After: canary: a few users first

    What changed

    • A bad release reaches few users before it is caught
    • Rolling back means shifting traffic back, not redeploying
    • You compare error rates between old and new

    Databases are the hard part

    Code can roll back instantly; data cannot. Use expand and contract:

    1. Expand: add new columns or tables, compatible with the old code.
    2. Deploy code that works with both shapes and writes to both if needed.
    3. Migrate data (backfill in batches).
    4. Contract: remove the old structure in a later release.

    Never combine a destructive schema change with the code that depends on it in one step.

    Checklist for safer releases

    • Automated tests and a staging environment that resembles production.
    • Health checks and automatic rollback on failure.
    • Monitoring on error rate and latency, watched during rollout.
    • Small, frequent changes over large, rare ones.
    • A written, practised rollback plan.

    More on this site

    Related reading

    Show 6 more

    Open this lesson with its quiz and exercise

  • Advanced Distributed Systems · 13 minKubernetes essentialsPods, deployments, services, ingress and operators: the building blocks of the most common container platform and how a request reaches a pod.Read here

    What Kubernetes does

    Kubernetes (K8s) runs containers across a cluster of machines. You describe the desired state (for example "three copies of this image, reachable at this address") and controllers continuously make reality match it: restarting failed containers, replacing lost nodes and rolling out new versions. (Containers themselves are introduced in the cloud models lesson.)

    The cluster

    • Control plane: the API server (everything talks to it), etcd (the consistent store of cluster state, built on Raft; see the consensus lesson), the scheduler (decides which node runs a pod) and controllers (reconcile desired and actual state).
    • Nodes: machines that run pods, each with a node agent (kubelet), a container runtime and a networking component.

    The core objects

    Figure SDA-ADS-07-1 · From request to pod · © forcsguy.com

    ObjectPurpose
    PodSmallest unit: one or more containers sharing network and volumes
    ReplicaSet / DeploymentKeep N pods running; roll out updates and roll back
    ServiceStable virtual IP and DNS name that load balances to matching pods
    IngressHTTP routing from outside to services (host, path, TLS), handled by an ingress controller
    ConfigMap / SecretConfiguration and sensitive values injected as environment variables or files
    StatefulSetPods with stable identity and storage, for databases and brokers
    DaemonSetOne pod per node (log shippers, agents)
    Job / CronJobRun to completion, once or on a schedule
    NamespaceLogical separation of resources and quotas
    PersistentVolume(Claim)Durable storage requested by pods

    Networking in one paragraph

    Every pod gets its own IP and can reach every other pod without NAT. Because pods are short-lived, clients use Services (found through cluster DNS such as orders.shop.svc). Network policies restrict which pods may talk to which. An Ingress (or the newer Gateway API) handles external HTTP(S) traffic.

    A deployment and a rolling update

    apiVersion: apps/v1
kind: Deployment
metadata: { name: web }
spec:
  replicas: 3
  selector: { matchLabels: { app: web } }
  strategy: { type: RollingUpdate, rollingUpdate: { maxSurge: 1, maxUnavailable: 0 } }
  template:
    metadata: { labels: { app: web } }
    spec:
      containers:
        - name: web
          image: example/web:1.4.2
          resources: { requests: { cpu: 200m, memory: 256Mi }, limits: { memory: 512Mi } }
          readinessProbe: { httpGet: { path: /healthz, port: 8080 } }

    Figure SDA-ADS-07-2 · Rolling update · © forcsguy.com

    Probes: readiness decides if a pod receives traffic; liveness decides if it should be restarted; startup gives slow starters time. Requests and limits tell the scheduler how much CPU and memory a pod needs and cap what it can use.

    Autoscaling

    A Horizontal Pod Autoscaler adds or removes pods by metrics such as CPU or request rate; a cluster autoscaler adds or removes nodes when pods cannot be placed. Scaling is useless without correct resource requests.

    Extending Kubernetes: operators and CRDs

    A Custom Resource Definition (CRD) adds a new object type (for example PostgresCluster). An operator is a controller that watches those objects and does the operational work (create replicas, take backups, fail over), encoding human runbooks as code. Many databases and brokers ship operators.

    Things that often go wrong

    Missing readiness probes (traffic to pods not ready), no resource requests (noisy neighbours, evictions), latest image tags (unrepeatable deploys), secrets in plain config, a single replica for a critical service, and running stateful systems without understanding storage and failure behaviour.

    Real-world reading

    Related reading

    Show 6 more

    Open this lesson with its quiz and exercise

  • Real-World Systems · 11 minShipping safely and handling a large outageHow strong teams build and operate software: small changes, automation, ownership, and a calm, practised response when things break.Read here

    How strong teams ship software

    Big companies deploy thousands of times a day and still stay up. The habits are surprisingly consistent.

    • Small teams own services end to end: "you build it, you run it". The people who write the code carry the pager, so they care about reliability.
    • Small, frequent changes: each change is easier to review, test, understand and undo than a large release.
    • Automation: a CI/CD pipeline builds, runs tests, scans for vulnerabilities and deploys without manual steps.
    • Safe rollout: canary releases, feature flags, blue-green switches, automatic rollback on bad metrics (see the deployment lesson).
    • Observability: metrics, logs and traces, with alerts on user-visible symptoms.
    • Testing in layers: unit, integration and end-to-end tests, plus load and failure testing.
    • Standard platforms and templates ("golden paths") so teams do not rebuild logging, deployment or monitoring each time.

    Figure SDA-RWS-15-1 · CI/CD with canary and rollback · © forcsguy.com

    When things break anyway

    Outages will happen. What separates good teams is how they respond.

    Figure SDA-RWS-15-2 · Incident response lifecycle · © forcsguy.com

    1. Detect

    Good alerts fire on symptoms users feel (errors, latency), quickly, and point to a dashboard and a runbook.

    2. Triage and roles

    Declare an incident and a severity. Assign clear roles so people do not all do the same thing:

    • Incident commander: coordinates and decides; does not debug.
    • Communications lead: updates stakeholders and customers.
    • Operations or subject experts: investigate and apply fixes.
    • A scribe keeps a timeline.

    3. Mitigate first

    Stop the bleeding before finding the cause. Typical moves, roughly from safest to most disruptive:

    • Roll back the last change, or turn off a feature flag.
    • Fail over to a healthy region or replica.
    • Shed load or degrade non-essential features.
    • Scale up or add capacity.

    The question is "what is the fastest safe way to reduce user harm?", not "why did this happen?".

    4. Communicate

    Update a status page and internal channels early and at a promised cadence, even when the news is "still investigating". Silence breeds panic and duplicate effort. State the impact, what you know, and when the next update comes.

    5. Resolve and verify

    Confirm recovery with metrics, not hope. Watch for relapse and clean up temporary measures.

    6. Learn: the blameless postmortem

    Within a few days write a postmortem: timeline, impact, causes (usually several), what went well, what did not, and action items with owners and dates. Ask "how did our system and process allow this?" instead of "who did this?". People who fear blame hide details, and the same failure returns.

    Reducing the next outage

    • Eliminate single points of failure and practise failover.
    • Game days and chaos testing: break things on purpose in controlled ways.
    • Load shedding, timeouts and circuit breakers so a local problem stays local (see the reliability lesson).
    • Capacity planning and error budgets so reliability work is scheduled, not forgotten.
    • Keep runbooks current and rehearse them. An on-call engineer at 3 a.m. should not be discovering the system for the first time.

    Real-world reading

    Related reading

    Show 6 more

    Open this lesson with its quiz and exercise

Continue to eBay

Go deeper on this

A path through videos, articles, other case studies and code on the same ideas as Lightweight Distributed Architecture to Handle Thousands of Library Releases at eBay.

  1. Warm upGet the vocabulary first.

  2. WatchHow others solve the same problem, on video.

    Videos belong to their creators and play from YouTube. More on YouTube (opens in a new tab)

  3. ReadEngineers explain it in their own words.

  4. See it in another companyThe same ideas, a different system.

  5. Read the codeSee how it looks when it is real.

Keep learning

Loading community…