feat(diagrams): editable design language for architecture figures - #478
Draft
mihir-datazip wants to merge 1 commit into
Draft
feat(diagrams): editable design language for architecture figures#478mihir-datazip wants to merge 1 commit into
mihir-datazip wants to merge 1 commit into
Conversation
Adds diagrams/ — one draw.io file, a shape library, and the generator that produces both — so architecture figures across the docs share a single visual vocabulary instead of being redrawn per post. - olake-architecture.drawio: 12 pages, page 00 is the legend - olake-shape-library.xml: 40 drag-and-drop components, glyphs and marks - tools/gen.py: emits the .drawio and the SVG previews from one source, so a change to a component restyles every page at once - previews/: rendered SVG of each page, for review
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this adds
A
diagrams/directory holding one editable source of truth for our architecture figures, plus the tooling to keep them consistent:olake-architecture.drawioolake-shape-library.xmlpreviews/pNN.svgtools/gen.py.drawioand the previews from the same component definitionstools/build_icons.py,tools/icons.jsonNothing else in the repo is touched — no blog or docs content changes here. The figures in the architecture deep-dive are still the old images; swapping them is a follow-up (see below).
Why
The nine images in the architecture deep-dive were each generated separately, so no symbol survived from one figure to the next:
Individually each image was fine. As a set they taught the reader a vocabulary and then broke it on the next scroll.
The design language
Defined once on page 00, obeyed by the other eleven:
#193AE6= OLake compute · slate = external systems · green = durable/committed · amber = state and bookkeeping · rose = failure and retry. Each is a 2px stroke over a light tint of the same hue.«interface», anIbadge and realmethod()signatures; an ordered log is a segmented tape with real events in its cells.ctid (0,1)–(4,0),0/1A2B3C4D,id 2 · Bob, actual Kafka offsets. Never placeholder boxes.Conventions were cross-checked against published guidance (C4 notation, draw.io's consistency guide, Ilograph's diagram-mistakes series, Excalidraw's palette formula) and against how the field actually draws these concepts — Kafka's log-anatomy figures, Netflix DBLog, PeerDB, Debezium's incremental-snapshot post, Confluent's DLQ post, Fivetran's hybrid deployment diagram.
How we unify diagrams across the rest of the docs
This is the part worth discussing in review — the file is only useful if the next person reaches for it.
1. Start from the library, not from a blank canvas. Open
diagrams/olake-architecture.drawio, then File → Open Library From → Device →olake-shape-library.xml. Every shape a data-pipeline diagram needs is already there — source systems with vendor marks, readers/writers, change-log tapes, chunks in four states, state files, destination tables, the glyph set. A new figure is assembled, not drawn.2. Page 00 is the contract. It is the legend and the reference sheet: the palette with its meanings, every component with its label, the interface notation, the edge grammar, the glyph template and the rules. Adding a new concept means adding its symbol to page 00 first, so the vocabulary grows deliberately instead of drifting.
3. Two ways to change things, and they don't mix.
.drawiodirectly (VS Code withhediet.vscode-drawio, app.diagrams.net, or the desktop app). Diffs land in git like any other file.tools/gen.pyand runcd diagrams/tools && python3 gen.py. Every component is one Python method that emits draw.io XML and preview SVG together, so changingcomponent()or theHUEtable restyles all twelve pages at once. Python 3 and the checked-inicons.jsonare the only requirements.4. One export recipe so figures look the same wherever they land: File → Export as → PNG, zoom 200%, border 0, white background (not transparent — the docs render on light and dark themes), then
cwebp -q 82intostatic/img/blog/....5. Where this scales next. The same vocabulary covers the connector docs, the Iceberg writer posts, and the exactly-once deep dive, which today each carry their own one-off images. Anything new gets added as a page in this file rather than a fresh canvas, so the whole documentation set converges on one look instead of diverging per author.
Reviewing this PR
Open
diagrams/previews/p00.svgfirst — it is the legend, and it explains every choice the other pages make. Thenp01(pipeline overview),p02(the interface diagram),p08/p09(the worked examples that follow real rows from source to destination).Follow-ups, not in this PR
blog/2026-07-22-deep-dive-into-olake-architecture.mdx(page 11 also covers the mermaid write-path block, if we want that visually consistent too).Draft while the language itself is up for discussion — the shapes and rules are the thing to argue about now, before figures get exported against them.