This document describes the architecture and data flow when reading build event data from BuildBuddy. Understanding this flow is essential for optimizing query performance and troubleshooting issues.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/buildbuddy-io/buildbuddy/llms.txt
Use this file to discover all available pages before exploring further.
Architecture Diagram
Overview
When a user or API client requests build event data (such as viewing an invocation in the UI or calling the GetInvocation API), BuildBuddy follows a specific path to retrieve and serve that data efficiently.Components Involved
Web UI / API Client
The entry point for read requests:- User navigates to an invocation page in the browser
- API client makes a GetInvocation request
- CLI tools query build data
API Server
Handles incoming requests:- Authenticates the request using API keys or session cookies
- Validates request parameters
- Routes to appropriate service handlers
- Formats and returns responses
Build Event Service
Core service for retrieving build data:- Queries the database for invocation metadata
- Retrieves associated targets, actions, and test results
- Applies filters and pagination
- Constructs response objects
Database
Stores structured build metadata:- Invocation records with status, timing, and user info
- Target records with labels, status, and timing
- Action records with file references
- Test results and logs references
Cache / Storage
Stores large blob data:- Build logs
- Test outputs
- Build artifacts
- Retrieved separately from metadata when needed
Data Flow
Step 1: Request Authentication
- Client sends request with authentication credentials
- API server validates API key or session token
- Authorization checks determine data access permissions
- Request is allowed to proceed or rejected
Step 2: Metadata Query
- Build Event Service constructs SQL query based on request
- Query includes filters (invocation ID, commit SHA, etc.)
- Database returns matching invocation records
- Associated targets and actions are fetched if requested
Step 3: Data Enrichment
- Service adds computed fields (duration, cache hit rate)
- Formats timestamps and status codes
- Constructs navigation links and URLs
- Applies any post-processing filters
Step 4: Blob Retrieval (Optional)
- If logs or artifacts are requested, service retrieves URIs
- Fetches blob data from storage backend
- Applies decompression if needed
- Includes blob data in response or provides signed URLs
Step 5: Response Construction
- Service assembles all data into response format
- Applies pagination (next_page_token)
- Serializes to JSON or Protocol Buffer
- Returns response to client
Performance Considerations
Database Indexing
Optimal indexes are critical for read performance:- Invocation ID (primary key)
- Commit SHA + created_at (for repo queries)
- User ID + created_at (for user history)
- Composite indexes for common filter combinations
Caching Strategies
- Metadata Caching: Frequently accessed invocations cached in memory
- CDN Caching: Static assets and public invocation pages
- Query Result Caching: Common queries cached for short periods
Pagination
Large result sets are paginated:- Default page size limits prevent oversized responses
- Cursor-based pagination for consistent results
- Clients use next_page_token for subsequent pages
Lazy Loading
Expensive data is loaded only when requested:- Build logs retrieved on-demand
- Artifacts loaded separately from metadata
- Child invocations fetched only if include_child_invocations=true