A shared view of TCGplayer's systems and technologies as an aggregate. A complement to, not a replacement for, OpsLevel, individual team documentation, or the Foundations repository.
-
Table of contents for TCGplayer architecture elements — Map the landscape of systems, services, components, and platforms we operate, at a level above individual team ownership.
-
A place for AI agents and people — Collaborate on understanding and documenting architecture, with contributions from both humans and AI systems.
-
Not a replacement for existing sources — OpsLevel is the service catalog. Team repositories hold detailed documentation. Foundations owns architectural direction (ADRs, RFCs). This repo surfaces the aggregate and points to those sources.
- technology-ownership — Focuses on who is responsible for each technology, lifecycle decisions, and cross-team obligations.
- OpsLevel — The live service catalog: teams, services, repositories, components.
- Foundations — Technical strategy, architectural principles, ADRs, and RFCs.
1. Platform & Infrastructure Layer
- CPE core platforms (Kubernetes, Terraform, GitHub, AWS infrastructure)
- Databases, caching, messaging (Kafka)
- Observability stack (New Relic, monitoring)
- CI/CD (Jenkins, Octopus, GitHub Actions)
2. Capability domains (cross-cutting concerns)
- Authentication & authorization
- Data access & APIs
- Security & compliance
- Performance & reliability
- Integrations (eBay, third-party services)
3. Technology landscape (organized by kind)
- Platform services (operated by one team)
- Shared libraries (open source tools)
- SaaS and vendor products
- Internal architectural patterns (Foundations ADRs/RFCs)
4. Application and product areas
- Organized by business domain or functional area
5. Organizational topology
- How teams, groups, and organizational structure relate to the above
This repo will include:
- System architecture diagrams — what systems exist and how they interact
- Platform dependency maps — which platforms enable which capabilities
- Cross-cutting concerns — how auth, observability, security span across systems
- Organizational alignment — how teams relate to architectural elements
Consider using the C4 Model or similar approaches for multi-level views (context → container → component).
- Thoughtworks Technology Radar — how to categorize and present a technology landscape
- Simon Brown's software architecture work — practical architecture patterns and C4 model
Solve the discoverability and relationships problem — not just "who owns this" but "here's what we have, how it fits together, and which teams operate which pieces." This is the aggregate view above individual team ownership and below architectural principles.