Imagine you have been using an online service for ten years. Over that decade, the service has collected your profile details, your messages, your photos, your purchase history, your search history, your location history, and dozens of other small fragments of your digital life. One day, you decide you want a copy of all of it — either because you want to move to a different service, or because you simply want to see what the company holds about you. This is exactly the problem a personal data export system (also called a data portability system or “data download” system) solves.

A data export system is a piece of infrastructure that, when triggered by a user, gathers every piece of personal data that a company’s various internal systems hold about that specific user, packages it into a human-readable and machine-readable format, and delivers it back to the user securely.

1.1 Where this requirement came from

For a long time, companies stored user data across dozens of internal databases and microservices, and there was no single place where “all of a user’s data” lived. Engineers could query one system at a time, but no one had built a way to pull everything together in one shot. Regulators eventually stepped in because users had a right to know, and a right to move their data elsewhere, without needing an engineering team to do it manually.

At first glance, “collect all the user’s data and zip it up” sounds simple. In a real company, it is one of the harder distributed systems problems you can be asked to design, because of a few specific difficulties:

The rest of this tutorial builds a system, piece by piece, that solves every one of these problems in a way that could plausibly run in production at a company with tens of millions of users.

2.1 Data ownership is never as clean as it looks

In theory, every piece of a user’s data belongs to exactly one service. In practice, large companies acquire other companies, merge platforms, and let old systems linger for years after a “replacement” was shipped. A user’s payment history might genuinely live in three different systems: an old legacy billing database that predates a platform migration, the current payments microservice, and a third-party payment processor’s records that get periodically synced back. A data export system has to grapple with this messiness rather than assume a clean, single source of truth exists for every domain.

2.2 Third-party and shared data

Not all data about a user is generated solely by that user. A group chat contains messages from multiple participants; a shared calendar event has attendees; a marketplace transaction has both a buyer and a seller. Deciding exactly how much of this “co-owned” data to include in one person’s export — and how much of it might reveal another person’s private information — is a genuine product and legal design decision that the engineering architecture must support, typically through per-domain redaction rules described later in this tutorial.

2.3 Why this is a genuinely hard distributed systems problem

It is worth being explicit about why this deserves a full system design treatment rather than a single background script. The core difficulty is coordinating many independent, unreliable, differently-owned systems toward one consistent outcome, under a hard deadline, while producing an artifact that is itself a major security risk if mishandled. That combination — distributed coordination, partial failure tolerance, deadline enforcement, and extreme sensitivity of the output — is what makes this a favorite topic in senior and staff-level system design interviews.

Before drawing any diagram, let’s define the vocabulary we will use throughout. Every term is explained with what it is, why it exists, and a simple example.

4.1 Functional requirements

• A logged-in user can request an export of all their personal data.
• The system collects data from every internal service that stores information about that user.
• The user receives a notification (email/push) when the export is ready.
• The user can download the export as a single compressed archive via a secure, time-limited link.
• The user can see the status of an in-progress request (pending, processing, ready, failed).
• Admins/compliance teams can audit every export request: who requested it, when, what was included, and who downloaded it.
• Users can request in specific formats where required (JSON for machine portability, human-readable HTML/PDF summary for readability).

These functional requirements deliberately go beyond “let the user click a button and get a file.” Status visibility matters because export jobs can take hours, and a user staring at a blank screen with no feedback will assume the feature is broken. Auditability matters because compliance teams, and sometimes regulators directly, need to demonstrate that the process actually works as documented — not just that it worked once during a demo.

4.2 Non-functional requirements

Now let’s put the pieces together. Every box in the diagram below plays a specific, named role — no generic “backend” boxes. This is the same shape of architecture you would sketch on a whiteboard in a real system design interview.

Let’s trace a single request end to end, from click to download, following the sequence below.

7.1 Lifecycle states

7.2 Case study walkthrough — following one real request

To make this concrete, let’s trace a single realistic request from start to finish. Meet Priya, a user who has had an account on the platform for six years, with data spread across a profile service, an orders service, a messaging service, a payments service, and a media service holding several hundred uploaded photos.

1. Priya opens her account settings and clicks “Download my data.” Because this is a sensitive action, the Auth Service requires her to re-enter her password before the request proceeds.
2. The Export Request Service creates a new row in the metadata database with status PENDING, publishes an export-requested event, and immediately returns a request ID to Priya’s browser along with an estimated ready time.
3. The Job Orchestrator picks up the event, updates status to PROCESSING, and dispatches five domain jobs — one each for profile, orders, messages, payments, and media.
4. Four of the five collectors finish within a couple of minutes. The media collector, however, needs to process several hundred photos and takes considerably longer, streaming files directly into staging storage rather than loading them all into memory.
5. Partway through, the payments collector fails due to a transient database timeout. The orchestrator retries it automatically after a short backoff delay, and the second attempt succeeds.
6. Once all five domains report DONE, the orchestrator moves the request to PACKAGING and triggers the Archive Packager.
7. The packager streams every domain’s staging file into a single compressed archive, adds a human-readable HTML summary, encrypts the result using a freshly generated data encryption key wrapped by the platform’s KMS master key, and uploads it to Final Object Storage.
8. The metadata database is updated to READY, and the Notification Service emails Priya a link to her account settings page (not the raw file link directly) where she can trigger a fresh signed URL on demand.
9. Priya clicks the download button. The Download Endpoint validates her session, generates a signed URL valid for the next few hours, and her browser downloads the encrypted archive directly from object storage.
10. Every step above — the original request, each domain’s completion, the packaging event, and the download itself — is written to the immutable audit log, giving the compliance team a complete, timestamped record if it is ever needed.

Seven days later, per the platform’s retention policy, the archive is automatically deleted from Final Object Storage, and the metadata record transitions to EXPIRED.

The metadata database is the source of truth for request state. A simplified relational schema:

-- export_requests: one row per user-initiated request
CREATE TABLE export_requests (
    id              UUID PRIMARY KEY,
    user_id         UUID NOT NULL,
    status          VARCHAR(20) NOT NULL,   -- PENDING, PROCESSING, READY, FAILED, EXPIRED
    requested_at    TIMESTAMP NOT NULL,
    ready_at        TIMESTAMP,
    expires_at      TIMESTAMP,
    archive_url_ref VARCHAR(255),           -- pointer to object storage key, not a raw signed URL
    format          VARCHAR(10) NOT NULL    -- JSON, JSON+HTML
);

-- export_domain_jobs: one row per domain per request
CREATE TABLE export_domain_jobs (
    id              UUID PRIMARY KEY,
    request_id      UUID REFERENCES export_requests(id),
    domain_name     VARCHAR(100) NOT NULL,  -- e.g. "orders", "messages"
    status          VARCHAR(20) NOT NULL,   -- QUEUED, RUNNING, DONE, FAILED
    attempt_count   INT DEFAULT 0,
    staging_key     VARCHAR(255),
    last_error      TEXT
);

-- export_audit_log: append-only, never updated or deleted
CREATE TABLE export_audit_log (
    id              BIGSERIAL PRIMARY KEY,
    request_id      UUID NOT NULL,
    event_type      VARCHAR(50) NOT NULL,   -- REQUEST_CREATED, DOMAIN_DONE, ARCHIVE_READY, DOWNLOADED
    actor_id        UUID,
    ip_address      VARCHAR(64),
    occurred_at     TIMESTAMP NOT NULL
);

8.1 Indexing strategy

Two query patterns dominate this schema, and the indexes should be built around them directly rather than added ad hoc later:

• “Find all requests for user X” — powers the export history endpoint, so an index on export_requests(user_id, requested_at) keeps this fast even for long-tenured users with many past requests.
• “Find all unresolved domain jobs for request Y” — the orchestrator checks this constantly while waiting for fan-in to complete, so an index on export_domain_jobs(request_id, status) keeps this check cheap even under heavy concurrent export volume.

The audit log table, by contrast, is optimized purely for appending and for occasional compliance-driven lookups by request_id, so a simpler index on request_id alone, plus reliance on the database’s natural insertion order for chronological reads, is normally sufficient.

This is the heart of the system. The orchestrator must reliably fan out to many independent services, and fan back in once they’re done, while tolerating partial failure. This is a variant of the well-known Saga pattern used for distributed transactions, adapted here for distributed data collection rather than distributed writes.

9.1 Orchestrator logic (Java example)

public class ExportOrchestrator {

    private final JobQueuePublisher jobQueue;
    private final ExportMetadataRepository metadataRepo;
    private final List<String> allDataDomains; // e.g. ["profile", "orders", "messages", ...]

    public void startExport(UUID requestId, UUID userId) {
        metadataRepo.updateStatus(requestId, ExportStatus.PROCESSING);

        for (String domain : allDataDomains) {
            DomainJob job = DomainJob.builder()
                    .requestId(requestId)
                    .userId(userId)
                    .domainName(domain)
                    .attemptCount(0)
                    .build();

            metadataRepo.saveDomainJob(job);
            jobQueue.publish("export.domain.job", job);
        }
    }

    // Called when a collector reports completion or failure
    public void onDomainJobResult(DomainJobResult result) {
        if (result.isSuccess()) {
            metadataRepo.markDomainDone(result.getJobId(), result.getStagingKey());
        } else if (result.getAttemptCount() < MAX_RETRIES) {
            retryWithBackoff(result);
        } else {
            metadataRepo.markDomainFailed(result.getJobId(), result.getError());
        }

        if (metadataRepo.allDomainsResolved(result.getRequestId())) {
            triggerPackaging(result.getRequestId());
        }
    }

    private void retryWithBackoff(DomainJobResult result) {
        long delayMs = (long) Math.pow(2, result.getAttemptCount()) * 1000;
        jobQueue.publishDelayed("export.domain.job", result.toRetryJob(), delayMs);
    }

    private void triggerPackaging(UUID requestId) {
        metadataRepo.updateStatus(requestId, ExportStatus.PACKAGING);
        jobQueue.publish("export.packaging.trigger", requestId);
    }
}

9.2 A single data collector (Java example)

// Lives inside the Orders microservice
public class OrdersExportCollector implements DataDomainCollector {

    private final OrdersRepository ordersRepository;
    private final ObjectStorageClient storageClient;

    @Override
    public DomainJobResult collect(DomainJob job) {
        try {
            List<Order> orders = ordersRepository.findAllByUserId(job.getUserId());

            String json = JsonWriter.toPortableJson(orders); // structured, machine-readable
            String stagingKey = "staging/" + job.getRequestId() + "/orders.json";

            storageClient.putEncryptedObject(stagingKey, json.getBytes(StandardCharsets.UTF_8));

            return DomainJobResult.success(job.getId(), job.getRequestId(), stagingKey);
        } catch (Exception e) {
            return DomainJobResult.failure(job.getId(), job.getRequestId(),
                    job.getAttemptCount() + 1, e.getMessage());
        }
    }
}

10.1 Packaging steps

1. Read every domain’s staging file for the request.
2. Validate each file against its expected schema (catch a collector bug before it reaches the user).
3. Generate a human-readable index/summary (often an HTML or PDF overview) alongside the raw JSON files.
4. Compress everything (domain JSON files, media files, the summary) into a single archive, typically .zip.
5. Encrypt the archive at rest using a per-archive data encryption key, itself encrypted by a master key held in a key management service (envelope encryption).
6. Upload to Final Object Storage with a lifecycle rule to auto-delete after the retention window.
7. Delete the staging files (they’ve served their purpose).

10.2 Signed URL generation (Java example)

public class DownloadUrlService {

    private final S3Presigner presigner;
    private static final Duration LINK_TTL = Duration.ofHours(24);

    public String generateSignedDownloadUrl(String objectKey) {
        GetObjectRequest getRequest = GetObjectRequest.builder()
                .bucket("final-export-archives")
                .key(objectKey)
                .build();

        GetObjectPresignRequest presignRequest = GetObjectPresignRequest.builder()
                .signatureDuration(LINK_TTL)
                .getObjectRequest(getRequest)
                .build();

        PresignedGetObjectRequest presigned = presigner.presignGetObject(presignRequest);
        return presigned.url().toString();
    }
}

10.3 Archive Packager (Java example)

The packager reads every completed domain’s staging file, validates it, and streams everything into a single compressed, encrypted archive without holding the whole thing in memory at once:

public class ArchivePackager {

    private final ObjectStorageClient storageClient;
    private final KmsClient kmsClient;
    private final ExportMetadataRepository metadataRepo;

    public void packageArchive(UUID requestId) {
        List<DomainJob> completedJobs = metadataRepo.getCompletedDomainJobs(requestId);
        List<DomainJob> failedJobs = metadataRepo.getFailedDomainJobs(requestId);

        String finalKey = "archives/" + requestId + "/export.zip";
        DataEncryptionKey dek = kmsClient.generateDataKey();

        try (OutputStream storageStream = storageClient.openUploadStream(finalKey);
             CipherOutputStream encryptedStream = dek.wrapStream(storageStream);
             ZipOutputStream zip = new ZipOutputStream(encryptedStream)) {

            for (DomainJob job : completedJobs) {
                addDomainFileToZip(zip, job);
            }

            if (!failedJobs.isEmpty()) {
                zip.putNextEntry(new ZipEntry("MISSING_DATA_NOTICE.txt"));
                zip.write(buildMissingDataNotice(failedJobs).getBytes(StandardCharsets.UTF_8));
                zip.closeEntry();
            }

            zip.putNextEntry(new ZipEntry("summary.html"));
            zip.write(buildHumanReadableSummary(completedJobs).getBytes(StandardCharsets.UTF_8));
            zip.closeEntry();

        } catch (IOException e) {
            metadataRepo.updateStatus(requestId, ExportStatus.FAILED);
            throw new PackagingException("Failed to build archive for " + requestId, e);
        }

        kmsClient.storeWrappedKeyReference(finalKey, dek.getWrappedKey());
        ExportStatus finalStatus = failedJobs.isEmpty()
                ? ExportStatus.READY
                : ExportStatus.PARTIAL_FAILURE;
        metadataRepo.markReady(requestId, finalKey, finalStatus);
    }

    private void addDomainFileToZip(ZipOutputStream zip, DomainJob job) throws IOException {
        zip.putNextEntry(new ZipEntry(job.getDomainName() + ".json"));
        try (InputStream in = storageClient.openDownloadStream(job.getStagingKey())) {
            in.transferTo(zip); // streams in chunks, avoids loading full file into memory
        }
        zip.closeEntry();
    }
}

Notice that addDomainFileToZip streams each staging file directly into the zip entry rather than reading it fully into a byte array first — this is the streaming approach referenced earlier that keeps memory usage roughly constant regardless of total archive size.

POST /api/v1/export/request
Authorization: Bearer <token>
Content-Type: application/json

{
  "format": "JSON_AND_HTML",
  "domains": ["ALL"]
}

Response 202 Accepted
{
  "requestId": "8f14e45f-ceea-4a2b-8b1a-1e2f3a4b5c6d",
  "status": "PENDING",
  "estimatedReadyBy": "2026-08-02T10:00:00Z"
}

11.1 Status polling vs webhooks

Clients need to learn when an export becomes ready. Two common approaches, often offered together:

• Polling: The client periodically calls GET /export/{requestId}/status. Simple to implement, but naive clients polling too aggressively can add unnecessary load — the API should return a Retry-After header suggesting a sensible polling interval.
• Push notification / webhook: The Notification Service emails or pushes the user directly when status changes to READY or FAILED, which is the primary mechanism in practice — polling exists mainly to support the “check status” button on a settings page.

11.2 Representative error responses

// Rate limited
HTTP 429 Too Many Requests
{
  "error": "RATE_LIMITED",
  "message": "You can request a new export once every 24 hours.",
  "retryAfterSeconds": 43200
}

// Requesting status of someone else's export (authorization failure)
HTTP 403 Forbidden
{
  "error": "FORBIDDEN",
  "message": "You do not have access to this export request."
}

// Attempting to download before it is ready
HTTP 409 Conflict
{
  "error": "NOT_READY",
  "message": "This export is still being prepared.",
  "status": "PROCESSING"
}

11.3 Advantages, disadvantages and trade-offs of this architecture

No architecture is free of trade-offs, and it’s worth being able to articulate these explicitly — in a system design interview, naming the cost of a decision alongside its benefit is usually more convincing than only listing benefits.

Because the output of this system is uniquely sensitive — one file containing everything about a person — security has to be treated as a first-class design concern, not an afterthought.

12.1 Rate limiter (Java example)

A simple token-bucket rate limiter, backed by Redis, prevents a single account from creating export requests faster than a reasonable pace (for example, one new request per 24 hours, with a small burst allowance):

public class ExportRateLimiter {

    private final StringRedisTemplate redis;
    private static final int MAX_REQUESTS_PER_WINDOW = 1;
    private static final Duration WINDOW = Duration.ofHours(24);

    public boolean allowRequest(UUID userId) {
        String key = "export-rate-limit:" + userId;
        Long count = redis.opsForValue().increment(key);

        if (count != null && count == 1L) {
            redis.expire(key, WINDOW);
        }

        return count != null && count <= MAX_REQUESTS_PER_WINDOW;
    }
}

12.2 Circuit breaker around a flaky collector (Java example)

If one domain’s collector service is unhealthy, a circuit breaker stops sending it new work for a cool-down period, instead of letting every export request pile up retries against a service that is clearly struggling:

public class CollectorCircuitBreaker {

    private final AtomicInteger consecutiveFailures = new AtomicInteger(0);
    private volatile Instant openUntil = Instant.EPOCH;
    private static final int FAILURE_THRESHOLD = 5;
    private static final Duration COOL_DOWN = Duration.ofMinutes(10);

    public boolean isOpen() {
        return Instant.now().isBefore(openUntil);
    }

    public void recordSuccess() {
        consecutiveFailures.set(0);
    }

    public void recordFailure() {
        int failures = consecutiveFailures.incrementAndGet();
        if (failures >= FAILURE_THRESHOLD) {
            openUntil = Instant.now().plus(COOL_DOWN);
        }
    }
}

When the breaker is open, the orchestrator routes affected domain jobs directly to a “deferred” state rather than dispatching them, and retries once the cool-down period elapses — protecting a struggling downstream service from being made worse by a flood of export traffic on top of whatever is already causing it trouble.

12.3 Defense in depth summary

13.1 Handling burst demand

Export requests are naturally spiky — a privacy news story, a regulatory deadline, or a competitor’s data breach can cause a sudden surge. Because the queue-based architecture decouples request intake from actual processing, the API layer can always respond quickly (202 Accepted) even while the backend processes a growing backlog at a sustainable rate. The job queue acts as a shock absorber.

13.2 Controlling load on downstream services

Fifty simultaneous export jobs each hitting the Orders database at once could degrade normal application traffic. Two common techniques address this:

• Per-domain concurrency limits: Cap how many concurrent export jobs any single downstream service will process, queuing the rest.
• Off-peak scheduling: For non-urgent bulk collection, schedule jobs to run during a domain’s known low-traffic window.

13.3 Large media files

Photos and videos can dominate archive size. Rather than routing large binary files through the packager, collectors for media-heavy domains can write directly to object storage and simply record references (keys) that the packager includes by reference in the final archive manifest, or streams directly into the zip without loading the whole file into memory.

13.4 Estimating capacity

A useful back-of-envelope exercise before building this system is estimating expected load. Suppose a platform has 50 million total users, and historically about 0.1% of active users request an export in a given month — that is roughly 50,000 requests per month, or a modest steady-state average of under two requests per minute. The real design challenge is not the average, but the tail: a single privacy-related news story or a bulk “delete my account” campaign can spike this by one or two orders of magnitude within a single day. Sizing the job queue, per-domain concurrency limits, and worker pool autoscaling around the 99th-percentile burst, not the average, is what keeps the system stable during exactly the moments it matters most.

An export system that quietly loses track of requests, or that cannot survive a single service restart without corrupting state, will eventually cause a missed regulatory deadline. The reliability techniques below are what make the difference between a demo-quality prototype and something safe to run in production.

14.1 Retries with exponential backoff

Transient failures — a downstream database briefly overloaded, a momentary network blip — are common at this scale and should not be treated as permanent failures. Retrying immediately, however, can make a struggling service worse by adding more load exactly when it’s least able to handle it. Exponential backoff (doubling the delay between each retry, as shown in the orchestrator code earlier) gives a struggling dependency room to recover between attempts.

14.2 Dead letter queues for persistent failures

Not every failure resolves itself through retries. Jobs that exhaust their retry budget are routed to a dead letter queue rather than being silently dropped or, worse, retried forever in a way that could mask a genuine, ongoing outage. A growing DLQ is itself a signal — as noted in the alerting table earlier — that something systemic needs attention.

14.3 Idempotent operations

Because retries are a normal part of this system’s operation, every write needs to be safe to repeat. Writing a domain’s staging file always overwrites the same key rather than appending, and status transitions check the current state before applying an update, so a duplicate message from an at-least-once delivery queue never corrupts the final result.

14.4 Durable workflow state

The orchestrator’s progress — which domains are done, which are still pending, how many retries each has used — is persisted outside the orchestrator process itself, either in the metadata database or in a workflow engine’s own durable execution log. This means a crash, a routine deployment, or an autoscaling event that kills and restarts the orchestrator does not lose in-flight requests; a new instance simply reads the persisted state and continues.

14.5 Multi-AZ and multi-region redundancy

Object storage buckets and the metadata database are configured for replication across multiple availability zones at minimum, so that a single data center outage doesn’t strand in-flight export requests or make a completed archive briefly or permanently unreachable.

14.6 Circuit breakers

As shown in the security section’s code example, a circuit breaker around each domain collector stops sending it new work once it starts failing consistently, giving it room to recover instead of compounding an existing problem — a small addition that meaningfully improves the system’s behavior during a partial outage.

Distributed tracing (e.g., via OpenTelemetry) is particularly valuable here, since a single export request’s trace spans dozens of services — being able to see one request’s full journey, end to end, across every collector, is essential for debugging a specific user’s failed export.

15.1 Example alerting rules

15.2 Multi-region and data residency

For a global platform, personal data is often stored in region-specific databases to satisfy data residency requirements — European user data staying within EU data centers, for example. The export system has to respect these same boundaries: a collector for a European user’s data should run within the EU region and write staging files to an EU-based bucket, rather than pulling everything into one central region for convenience. The orchestrator becomes region-aware, routing each domain job to the correct regional deployment of that collector, and the final archive is assembled and stored in the region tied to the requesting user’s data residency requirements.

16.1 Containerized, independently scalable services

The Export Request Service, Orchestrator, Packager, and Notification Service are best deployed as separate containerized services on an orchestration platform such as Kubernetes, each with its own horizontal pod autoscaler. This matters because these components have very different load profiles: the Export Request Service scales with incoming HTTP traffic, while the Packager scales with completed jobs waiting to be assembled — coupling them into one monolithic deployment would force one component’s scaling needs onto all the others.

16.2 Managed messaging infrastructure

Running your own message broker cluster is a significant operational burden — patching, scaling, and monitoring a distributed queueing system is a full discipline on its own. Using a managed offering such as Amazon SQS/SNS, a managed Kafka service, or Google Pub/Sub lets the team focus engineering effort on the export system’s actual business logic rather than on operating queue infrastructure.

16.3 Object storage lifecycle rules

Cloud object storage services natively support automatic expiration policies at the bucket or prefix level. This is precisely how the retention window requirement described earlier gets enforced in practice — rather than writing and maintaining a custom cleanup job that must run reliably forever, a single storage lifecycle rule declares “delete anything under this prefix after N days” and the cloud provider guarantees it happens, removing an entire class of potential bugs around forgotten or failed cleanup jobs.

16.4 Infrastructure as Code

Given how compliance-sensitive this system is, its infrastructure — bucket policies, retention rules, IAM roles governing which services can read which staging buckets — is best defined declaratively using a tool such as Terraform rather than configured by hand through a cloud console. Every change to a bucket’s retention policy or a collector’s IAM permissions then goes through the same code review process as application code, producing a reviewable, auditable history of exactly when and why access controls changed — itself a useful artifact during a compliance audit.

16.5 Blue-green and canary deployments

Because in-flight export requests can span many hours, deploying a new version of the orchestrator carelessly risks disrupting active workflows mid-execution. A blue-green or canary deployment strategy, combined with the durable workflow state described in the reliability section, lets new orchestrator versions roll out gradually while existing in-flight requests continue running against whichever version they started with, or safely resume on the new version thanks to persisted state.

17.1 Patterns used

17.2 Anti-patterns to avoid

18.1 Practices worth adopting

18.2 Common mistakes to avoid

Across all of these examples, three architectural choices repeat consistently: the request is always handled asynchronously with a notification on completion, the output almost always offers a structured machine-readable format to satisfy portability requirements, and the download is always delivered through a time-limited, authenticated link rather than an email attachment or an always-public URL.

20.1 Identity verification before fulfilling a request

Regulators generally expect a company to take reasonable steps to confirm a data export request genuinely comes from the account holder before releasing anything, precisely because the archive is so sensitive. This is exactly why the architecture places step-up authentication in front of the Export Request Service rather than treating a valid session alone as sufficient — the legal requirement to verify identity directly motivates a concrete engineering control.

20.2 Response deadlines are a first-class system constraint

Most portability laws specify a maximum response time, and many allow a one-time extension for complex requests if the company notifies the user within the original window. Practically, this means the metadata database’s requested_at timestamp isn’t just informational — it should feed directly into the alerting rules described in the monitoring section, so an approaching deadline breach pages an engineer well before it becomes a compliance incident, not after.

20.3 Cross-border data transfer

When a user downloads their archive, that download itself can constitute a data transfer, and if the user is located in a different country than where their data resides, some jurisdictions have specific rules about transfers to certain destinations. This rarely changes the architecture significantly, since the download is triggered directly by the data subject themselves rather than the company choosing to move data elsewhere, but it is worth documenting in a system’s compliance review.

Not everything a system stores about a user should necessarily go into the export, and not everything in a co-owned record (like a group chat) should reveal a third party’s private details. This section covers how the architecture handles that boundary.

21.1 What typically gets excluded or redacted

• Other users’ personal data inside shared records: In a group chat export, other participants’ display names might be retained for context, but their own private account details (email, phone number) are not included just because they appear in a shared thread.
• Internal fraud and risk signals: Some jurisdictions and legal interpretations allow excluding internal risk-scoring data if disclosing it would materially undermine fraud prevention effectiveness — this is a legal determination made per-domain, not a default assumption.
• Data about other people entirely: If User A is mentioned in User B’s support ticket, that ticket belongs to User B’s export, not User A’s, even though User A is named in it.

21.2 Where redaction happens in the architecture

Redaction logic lives inside each domain’s own collector, not in a central “scrub everything” step. The team that owns the Messaging service is best positioned to know which fields in a message record are safe to export and which belong to someone else, exactly the same ownership argument made earlier for why collectors are decentralized in the first place.

public class MessagesExportCollector implements DataDomainCollector {

    @Override
    public DomainJobResult collect(DomainJob job) {
        List<Message> rawMessages = messageRepository.findAllInvolvingUser(job.getUserId());

        List<ExportableMessage> redacted = rawMessages.stream()
                .map(m -> ExportableMessage.builder()
                        .messageId(m.getId())
                        .sentAt(m.getSentAt())
                        .content(m.getContent())
                        .otherParticipantDisplayName(m.getOtherParticipant().getDisplayName())
                        // deliberately NOT including other participant's email, phone, or internal ID
                        .build())
                .collect(Collectors.toList());

        return writeAndUpload(job, redacted);
    }
}

Because this system’s failure modes are unusually costly — either missing legally required data, or leaking someone else’s private information — testing deserves particular attention beyond typical unit tests.

Full data exports are inherently more expensive per request than typical read traffic, because a single request touches dozens of services and produces a potentially large file that must be stored, even temporarily. A few techniques keep this sustainable at scale:

• Tiered domain collection: Cheap, fast domains (profile, settings) are collected first and can be made available quickly; expensive domains (full media libraries, long streaming history) can be offered as a separate, slower-arriving tier, similar to the Spotify example above.
• Compression before storage: Compressing text-heavy domains (JSON, logs, message history) before writing to staging storage significantly reduces both storage cost and the final archive size, since structured text compresses very well.
• Short retention windows: A shorter retention period (for example, 7 days instead of 30) reduces steady-state storage cost while still giving users a reasonable window to download, and it doubles as a security improvement.
• Off-peak scheduling for non-urgent bulk exports: Where the legal deadline allows some flexibility, scheduling the heaviest collection jobs during a domain’s low-traffic hours reduces the need for over-provisioning downstream services purely to absorb export load.
• Right-sized worker autoscaling: Scaling collector worker pools based on queue depth, rather than a fixed always-on fleet sized for worst-case burst, keeps steady-state compute cost proportional to actual demand.

26.1 Quick recap — if asked to whiteboard this in 10 minutes

1. Start with the client-to-gateway path: Client → CDN → Load Balancer → WAF → API Gateway → Auth Service.
2. Show the request being accepted (202) and dropped onto a queue, with a metadata database recording status.
3. Draw the orchestrator fanning out to N domain collectors in parallel, each writing to staging storage.
4. Show fan-in back to the orchestrator, then the packager building the final encrypted archive once all domains resolve (success or permanent failure).
5. Close the loop with a signed URL, a notification, and an audit log entry for every meaningful event.
6. Mention retries, DLQs, and rate limiting proactively — these are exactly what separates a senior-level answer from a junior one on this specific problem.