Post-Cortex: Persistent Memory for AI Assistants

2026-05-09T00:00:00+00:00

The thing that frustrates me most about working with AI assistants is the amnesia. Every new session starts from zero. Decisions made yesterday are gone. Problems debugged last week are debugged again. Context I painstakingly built up over a long conversation evaporates the moment I close the terminal.</p>

Post-Cortex</a> is my answer to that. It is an MCP server that gives AI assistants long-term memory — a local, searchable knowledge base of conversations, decisions, and insights, with automatic entity extraction and a knowledge graph built on top.</p>

What it is</a></h2>
Post-Cortex sits between your AI client (Claude, Cursor, anything that speaks MCP) and a local store. Every meaningful exchange — a Q&A, a decision, a bug fix, a code change — gets logged into a session. Sessions live in workspaces. Across all of them, semantic search and entity-graph queries let the assistant find what it already knows before it asks you again.</p>
The design constraints are deliberate:</p>

Local-first.</strong> All processing runs on your machine. No external APIs, no telemetry, no opaque cloud index of your work.</li>
Fast.</strong> Lock-free Rust architecture, HNSW vector search at O(log n), sub-10ms queries.</li>
Flexible storage.</strong> Embedded RocksDB by default for zero-config use, SurrealDB when you want distribution.</li>
Graph-RAG.</strong> Search results come back enriched with entity relationships, not just bag-of-text matches.</li> </ul> Install</a></h2>
`# Homebrew (macOS / Linux) brew install julymetodiev/tap/post-cortex # Or grab the binary directly curl -L https://github.com/julymetodiev/post-cortex/releases/latest/download/pcx-aarch64-apple-darwin -o /usr/local/bin/pcx chmod +x /usr/local/bin/pcx </code></pre> The binary is pcx</code>. Verify with pcx --version</code>.</p>`Wiring</a></h2> Post-Cortex is registered once, globally, and then every project on your machine gets memory for free.</p> # HTTP transport (recommended — requires the daemon) claude mcp add --scope user --transport http post-cortex http://127.0.0.1:3737/mcp # Stdio transport (no daemon needed) claude mcp add --scope user --transport stdio post-cortex -- pcx </code></pre> Then per project:</p> pcx setup </code></pre> pcx setup</code> creates a session, a workspace, a CLAUDE.md</code> with memory rules, hooks that enforce them, and installs the agent definitions that let Claude know it has memory tools available. After that:</p> claude </code></pre> Claude will search past knowledge before answering, and log new discoveries as it makes them. The whole thing is invisible most of the time — until the moment your assistant says "we already decided this last week, here is the rationale" and you remember why you wanted it in the first place.</p> Tools</a></h2> Six tools, deliberately small:</p> Tool</th> Purpose</th></tr></thead> session</code></td> Create and list sessions</td></tr> update_conversation_context</code></td> Store knowledge — Q&A, decisions, problems, code changes</td></tr> semantic_search</code></td> Find related content across sessions, workspaces, or globally</td></tr> get_structured_summary</code></td> Session overview — decisions, insights, entities</td></tr> query_conversation_context</code></td> Entity relationships + keyword search</td></tr> manage_workspace</code></td> Organize sessions into workspaces</td></tr> </tbody></table> The split between semantic_search</code> and query_conversation_context</code> matters: semantic search is for "what do I already know about X", graph queries are for "how is X related to Y". Both are cheap; both run locally.</p> Daemon mode</a></h2> If you run multiple Claude instances — different terminals, different projects, an editor integration on the side — they should all share the same memory. The daemon is what makes that possible.</p> pcx start # start daemon pcx status # check status pcx stop # stop daemon </code></pre> With the daemon up, the HTTP transport is the right choice:</p> { "mcpServers": { "post-cortex": { "type": "http", "url": "http://localhost:3737/mcp" } } } </code></pre> One process owns the store, every client talks to it over JSON-RPC, and there is no lock contention or split-brain to worry about.</p> Storage</a></h2> </th> RocksDB (default)</th> SurrealDB</th></tr></thead> Setup</td> Zero config</td> Requires server</td></tr> Distribution</td> Embedded</td> Distributed</td></tr> Vector search</td> HNSW O(log n)</td> HNSW O(log n)</td></tr> </tbody></table> Both back the same MCP API; the choice is about deployment, not features. RocksDB is what you want on a laptop. SurrealDB is what you want when several machines should share the graph.</p> Configure in ~/.post-cortex/daemon.toml</code> or override with environment variables:</p> Variable</th> Default</th> Description</th></tr></thead> PC_HOST</code></td> 127.0.0.1</code></td> Bind address</td></tr> PC_PORT</code></td> 3737</code></td> Port</td></tr> PC_DATA_DIR</code></td> ~/.post-cortex/data</code></td> Storage location</td></tr> PC_STORAGE_BACKEND</code></td> rocksdb</code></td> rocksdb</code> or surrealdb</code></td></tr> </tbody></table> Backups</a></h2> Memory you cannot back up is not memory you can rely on. Post-Cortex ships export/import as first-class commands:</p> pcx export --output backup.json # full export pcx export --output backup.json.gz # compressed pcx import --input backup.json # restore </code></pre> The export is a plain JSON document. You can diff it, version it, copy it to another machine, or feed it into your own tooling.</p> Why local</a></h2> The reason this had to be local, not a hosted service, comes down to two things:</p> Trust.</strong> The whole point of memory is that it accumulates over months and years. The notes, the decisions, the half-formed ideas — that is exactly the material I am not willing to hand to a third party indefinitely.</li> Latency.</strong> Sub-10ms queries change how an assistant uses memory. If every recall is a network round-trip, the model treats memory as expensive and avoids it. If it is a local function call, the model uses it constantly. The behaviour shifts.</li> </ol> Static, on-disk, on-CPU is what makes both of those possible. HNSW gives logarithmic vector search; RocksDB gives durable storage without a server; the lock-free hot path keeps the daemon responsive under concurrent reads.</p> Future</a></h2> Post-Cortex is the storage layer in a larger pattern I keep coming back to: assistants should remember, search, and reason locally</strong>. Veles</a> does the search side over code. Post-Cortex does the memory side over conversations and decisions. Together they cover most of what an agent needs to act usefully on a long-lived project without sending anything off the machine.</p> If you try it and something feels off, open an issue</a> — I read all of them.</p> Using Veles: Fast Hybrid Local Code Search for AI Agents and Humans 2026-05-09T00:00:00+00:00 I built Veles</a> because I kept hitting the same wall on every large codebase: grep</code> is fast but literal, semantic search needs a GPU and an API key, and most "AI code search" tools assume you are willing to ship your source somewhere. None of that fits how I actually work locally, on CPU, with the index living next to the code.</p> Veles is a hybrid (BM25 + semantic) local code search engine, written in pure Rust. It runs entirely on CPU, persists its index on disk, exposes itself over CLI, MCP and gRPC, and returns results in tens of milliseconds.</p> What it is</a></h2> Veles is a small toolbox built around one idea: good code search is hybrid</strong>. Pure lexical search misses paraphrases. Pure semantic search misses identifiers. Reciprocal Rank Fusion blends the two and consistently outperforms either alone for code.</p> On top of that core it adds the things you actually want from a daily-driver:</p> A persistent on-disk index under <repo>/.veles/</code>, with incremental updates.</li> Tree-sitter symbols</code> / defs</code> / refs</code> for Rust, Python, JavaScript, TypeScript, and Go.</li> An identifier-aware tokenizer that splits camelCase</code>, snake_case</code>, and mixed scripts.</li> Query-type detection that biases symbol-like queries toward BM25 and natural-language queries toward semantic.</li> Six pipe-friendly output formats (pretty</code>, compact</code>, ripgrep</code>, paths</code>, json</code>, jsonl</code>).</li> An MCP server so Claude, Cursor, and other agents can use it as a first-class search tool.</li> </ul> Static embeddings come from the potion</a> family via model2vec-rs</a>. No transformer forward pass at query time — that is what makes the latency predictable.</p> Install</a></h2> Pick whichever path fits your environment:</p> # macOS / Linux — prebuilt binary curl --proto '=https' --tlsv1.2 -LsSf \ https://github.com/julymetodiev/Veles/releases/latest/download/veles-cli-installer.sh | sh # Homebrew brew install julymetodiev/tap/veles-cli # From crates.io cargo install veles-cli # Windows (PowerShell) irm https://github.com/julymetodiev/Veles/releases/latest/download/veles-cli-installer.ps1 | iex </code></pre> Verify the install:</p> $ veles --version veles 0.2.2 </code></pre> The three commands</a></h2> Build the index, search it, refresh it. Here is what each one looks like against the Veles repo itself (32 source files):</p> $ veles index . Indexed 32 files / 190 chunks in 0.17s — saved to ./.veles </code></pre> $ veles search "parse config file" -f compact crates/veles-cli/src/handlers.rs:46-95 [score=0.015] let path_slice: Option<&[String]> = glob_paths.as_deref(); crates/veles-core/src/walker.rs:46-95 [score=0.010] ".ts", crates/veles-core/src/ranking/penalties.rs:91-140 [score=0.010] let pool = top_k_indexed(&penalised, pool_size); crates/veles-core/src/persist.rs:136-185 [score=0.009] dir.join(MANIFEST_FILE).is_file() crates/veles-core/src/symbols.rs:136-185 [score=0.009] let name = match name_node.utf8_text(source_bytes) { </code></pre> $ veles update . Index is up to date (190 chunks, no changes). </code></pre> The first search</code> downloads the embedding model (~64 MB) into ~/.cache/huggingface/hub/</code>. After that everything is local. update</code> reuses embeddings of files whose (size, mtime)</code> fingerprint has not changed, so refreshing after a small edit is near-instant even on large repos.</p> veles status</code> is the diagnostic — model, dimension, chunk counts, and an on-disk diff against the manifest:</p> $ veles status Index at ./.veles veles version : 0.2.2 format version : 2 model : minishlab/potion-code-16M embedding dim : 256 text files : false indexed at : 1778349001 (unix) files in manifest: 32 total chunks : 190 On-disk diff: files seen now : 32 added : 0 modified : 0 removed : 0 </code></pre> Searching</a></h2> The default mode is hybrid, but you can pin the mode when you know what you want. The clearest way to see the difference is to run a symbol query through BM25 and a concept query through semantic, side by side:</p> $ veles search "BM25 inverted index" -m bm25 -f compact -t 3 crates/veles-core/examples/bm25_compare.rs:181-230 [score=12.978] let queries: Vec<Vec<String>> = [ crates/veles-core/src/index/sparse.rs:1-50 [score=12.139] //! BM25 sparse index — inverted-index implementation with token interning. crates/veles-core/examples/bench.rs:1-50 [score=11.649] //! Quick wall-clock benchmark for indexing + querying. </code></pre> $ veles search "how the index gets persisted to disk" -m semantic -f compact -t 3 crates/veles-core/src/persist.rs:1-50 [score=0.887] //! Persistent on-disk index format. crates/veles-core/src/persist.rs:46-95 [score=0.886] /// content hashing can be layered on later if needed. crates/veles-core/src/lib.rs:46-95 [score=0.887] //! # } </code></pre> BM25 lands on the literal BM25 sparse index</code> doc-comment first; semantic lands on persist.rs</code> even though the query never says "persist". That gap is what hybrid is closing — the default mode runs both and fuses the rankings via RRF.</p> Filters compose cleanly with globs and language hints:</p> veles search "auth" -l rust,python # language filter veles search "X" -g 'src/**/*.rs' -x 'src/legacy/**' # include / exclude veles search "BM25" --min-score 0.4 # drop weak hits </code></pre> The output formats are designed to flow into Unix pipelines. rg</code> mode is drop-in compatible with anything that already consumes ripgrep:</p> $ veles search "rate limiting" -f rg | head -5 crates/veles-core/src/ranking/boosting.rs:451: "PREVIEW_FILE_CACHE", crates/veles-core/src/ranking/boosting.rs:452: "_private_thing", crates/veles-core/src/ranking/boosting.rs:453: "foo::bar", crates/veles-core/src/ranking/boosting.rs:454: "module::Type", crates/veles-core/src/ranking/boosting.rs:455: "obj->method", </code></pre> paths</code> mode strips everything except file paths — exactly what xargs</code> wants:</p> $ veles search "rate limiting" -f paths crates/veles-core/src/ranking/boosting.rs crates/veles-core/src/walker.rs crates/veles-cli/src/tui/app.rs crates/veles-mcp/src/lib.rs crates/veles-core/src/veles_index.rs </code></pre> json</code> is structured for tooling and agents:</p> $ veles search "rate limiting" -f json -t 1 | jq '.results[0] | {file_path, start_line, end_line, score, language}' { "file_path": "crates/veles-core/src/walker.rs", "start_line": 136, "end_line": 185, "score": 0.00970386039132734, "language": "rust" } </code></pre> That paths</code> mode is the small trick that turns search into navigation:</p> veles search "rate limiting" -f paths | xargs $EDITOR </code></pre> Symbols</a></h2> grep -w SymbolName</code> is a poor approximation of "find this definition". Veles uses tree-sitter to do it properly. symbols</code> is the file outline:</p> $ veles symbols crates/veles-core/src/persist.rs Symbols in crates/veles-core/src/persist.rs const INDEX_DIR_NAME crates/veles-core/src/persist.rs:31 const FORMAT_VERSION crates/veles-core/src/persist.rs:35 const MANIFEST_FILE crates/veles-core/src/persist.rs:37 struct FileFingerprint crates/veles-core/src/persist.rs:48 struct Manifest crates/veles-core/src/persist.rs:80 struct PersistedIndex crates/veles-core/src/persist.rs:144 function save crates/veles-core/src/persist.rs:153 function load crates/veles-core/src/persist.rs:173 function load_manifest crates/veles-core/src/persist.rs:207 function clean crates/veles-core/src/persist.rs:213 ... </code></pre> defs</code> resolves a name across the whole repo, optionally narrowed by kind and language:</p> $ veles defs Manifest Definitions of "Manifest" struct Manifest crates/veles-core/src/persist.rs:80 </code></pre> $ veles defs save -k function -l rust Definitions of "save" function save crates/veles-core/src/persist.rs:153 function save crates/veles-core/src/veles_index.rs:139 </code></pre> refs</code> does both — it lists the definitions, then the BM25 hits across chunks so you see every callsite, doc-comment, and test that mentions the symbol:</p> $ veles refs save -t 5 -f compact crates/veles-core/src/persist.rs:153 function save crates/veles-core/src/veles_index.rs:139 function save crates/veles-core/src/veles_index.rs:136-185 [score=3.662] /// Persist the index to `<repo_root>/.veles/`. crates/veles-cli/src/cli.rs:1-50 [score=3.554] //! Command-line interface definition (clap derives). crates/veles-core/examples/bm25_compare.rs:181-230 [score=2.838] let queries: Vec<Vec<String>> = [ </code></pre> This is the workflow I use the most when navigating an unfamiliar codebase: defs</code> to land on the canonical definition, then refs</code> to fan out.</p> The TUI</a></h2> veles tui </code></pre> </p> Loads the persistent index once, then debounces queries so each keystroke re-runs in tens of milliseconds. ↑↓</code> navigate, Tab</code> cycles hybrid</code> / bm25</code> / semantic</code>, Ctrl-R</code> finds related code, Enter</code> prints path:line</code> to stdout, Ctrl-O</code> opens the result in $EDITOR</code>. ?</code> shows the full keybinding overlay.</p> The handy bit: because Enter</code> prints path:line</code>, you can use the TUI as a picker:</p> $EDITOR $(veles tui) </code></pre> MCP</a></h2> This is what pushed me to build it in the first place. AI agents are good at writing code, but only if they can find the right code to read. Vague greps and unbounded reads burn the context window fast.</p> Veles ships an MCP server over stdio. Wire it into Claude Code or any other MCP-aware client and the agent gets two tools: search</code> and find_related</code>. From the client's perspective:</p> veles serve-mcp # explicit veles # equivalent — bare `veles` starts MCP when stdin is piped </code></pre> The agent then asks targeted questions ("where do we parse config?", "what is similar to this function?") and gets back a small, ranked, file-bounded set of chunks instead of a recursive grep dump. In practice this is the difference between an agent that wanders and one that lands on the right file on the first try.</p> There is also a gRPC service (veles serve-grpc</code>) for non-MCP integrations.</p> Embedding</a></h2> If you want the engine without the binary, pull veles-core</code>:</p> [dependencies] veles-core = "0.2" </code></pre> use std::path::Path; use veles_core::{SearchMode, VelesIndex}; let index = VelesIndex::from_path(Path::new("."), None, None, false)?; let results = index.search("parse config", 5, SearchMode::Hybrid, None, None, None); for r in results { println!("{} [{:.3}]", r.chunk.location(), r.score); } </code></pre> The workspace also publishes veles-grpc</code>, veles-mcp</code>, and veles-cli</code> separately, so you can compose only the layers you need.</p> Index layout</a></h2> .veles/ manifest.json # model, dim, per-file (size, mtime, chunk_count) chunks.bin # bincode Vec<Chunk> bm25.bin # bincode BM25 inverted index dense.bin # bincode dense matrix symbols.bin # bincode tree-sitter symbols </code></pre> Everything is bincode-serialized and lives next to the code. Nothing leaves the machine, nothing depends on a network round-trip at query time, and the on-disk format is small enough to commit-and-forget if you want builds to skip the index step.</p> CPU-only</a></h2> A lot of the design decisions in Veles fall out of one constraint: no GPU, no API call, no transformer forward pass at query time</strong>. That is what makes static embeddings (model2vec / potion) the right choice — they are precomputed once at indexing time, and queries become a vector lookup plus a BM25 scan plus a fusion step. The result is latency that does not depend on model load, network, or GPU availability.</p> It also means Veles works the same way on your laptop, in CI, in a dev container, and over SSH on a constrained box. That portability is the thing I value most when I am switching between machines all day.</p> Future</a></h2> Veles started as a Rust port of the Semble</a> hybrid retrieval recipe and grew into something I use every day. The roadmap is mostly driven by what I keep wanting at the keyboard: more languages in the symbol layer, smarter query-type detection, and tighter integration with the agents I run locally.</p> If you try it and something feels off, open an issue</a> — I read all of them.</p> veles search "what should I read first" </code></pre> Veles 2026-05-01T00:00:00+00:00 Fast hybrid (BM25 + semantic) local code search for AI agents and humans, written in pure Rust.</p> </p> Capabilities</h3> Tech:</strong> Rust, tree-sitter, model2vec, BM25, MCP, gRPC (tonic), Tokio</li> Purpose:</strong> Millisecond-latency code search over a persistent on-disk index — no GPU, no API calls</li> Features:</strong> Hybrid retrieval with Reciprocal Rank Fusion, identifier-aware tokenizer, query-type detection, definition boosting, file saturation</li> Symbols:</strong> Tree-sitter symbols</code> / defs</code> / refs</code> for Rust, Python, JavaScript, TypeScript, Go</li> Interfaces:</strong> CLI, interactive TUI, MCP stdio server, gRPC service, six pipe-friendly output formats</li> Distribution:</strong> Published crates (veles-cli</code>, veles-core</code>), prebuilt binaries for macOS / Linux / Windows, Homebrew tap</li> Focus:</strong> CPU-only static embeddings, persistent + incremental indexing, AI-agent integration (Claude, Cursor)</li> </ul> Post-Cortex 2025-11-17T00:00:00+00:00 Post-Cortex is an MCP server that gives AI assistants long-term memory. It stores conversations, decisions, and insights in a durable, searchable knowledge base — with automatic entity extraction and a graph built on top of every write.</p> The design constraints are deliberate:</p> Local-first.</strong> All processing runs on your machine. No external APIs, no telemetry, no opaque cloud index of your work.</li> Fast.</strong> Lock-free Rust architecture, HNSW vector search at O(log n), single-digit-ms write latency on warm paths, ms-per-text Model2Vec inference.</li> Flexible storage.</strong> Embedded RocksDB by default for zero-config use, SurrealDB when you want distribution.</li> Graph-RAG.</strong> Search results come back enriched with entity relationships, not just bag-of-text matches.</li> </ul> Workspace layout</h3> Post-Cortex is a Cargo workspace of eight publishable crates</strong>. Downstream Rust projects can pick whichever layer they actually need — post-cortex-core</code> carries no transport, I/O or ML dependencies, so it can be consumed for the type system alone without dragging in RocksDB, Candle, or the server stack.</p> Crate</th> Pick when you need…</th></tr></thead> post-cortex</code></a></td> The full stack in one dep</td></tr> post-cortex-core</code></a></td> Domain types + traits only (no I/O, no ML)</td></tr> post-cortex-proto</code></a></td> gRPC wire types (client-side)</td></tr> post-cortex-embeddings</code></a></td> Model2Vec (default) + BERT embedders + HNSW vector DB</td></tr> post-cortex-storage</code></a></td> RocksDB + SurrealDB backends</td></tr> post-cortex-memory</code></a></td> ConversationMemorySystem</code> orchestrator</td></tr> post-cortex-mcp</code></a></td> MCP tool functions (embed in any MCP host)</td></tr> post-cortex-daemon</code></a></td> pcx</code> CLI + rmcp/axum/tonic server</td></tr> </tbody></table> MCP surface</h3> The pcx</code> daemon exposes a small but expressive MCP toolset — session</code>, update_conversation_context</code> (with required typed entities</code> + relations</code> arrays as of 0.3.0), bulk_update_conversation_context</code>, semantic_search</code>, get_structured_summary</code>, query_conversation_context</code>, assemble_context</code> (graph-aware retrieval), manage_workspace</code>, manage_entity</code>, and admin</code> (health, vectorize-session, vectorize-stats, checkpoints). Same canonical write path under all of them.</p> Release line</h3> The current release is 0.3.0</strong> — Model2Vec embedder by default, non-blocking write pipeline, and the canonical single-entrypoint write contract. CI enforces cargo fmt</code>, clippy -D warnings</code>, cargo deny check</code>, and cargo audit</code> on every push to main</code>.</p> rust-mexc-ws 2025-06-01T00:00:00+00:00 Role:</strong> Creator / Lead Developer Timeline:</strong> 2025 — Present Status:</strong> Open Source / Production Ready</p> Key Features</h3> Production-grade WebSocket client for MEXC exchange</li> Protocol Buffers support for minimal latency</li> HFT-ready architecture with sub-millisecond performance</li> Zero-panic design with comprehensive safety mechanisms</li> Multithreaded architecture supporting 1,300+ msgs/sec sustained throughput</li> Memory-bounded operations with automatic cleanup</li> </ul> Technical Stack</h3> Language:</strong> Rust (100% safe code, zero unsafe blocks)</li> Protocols:</strong> WebSocket, Protocol Buffers, gRPC</li> Architecture:</strong> Lock-free design, ring buffers, object pools</li> Concurrency:</strong> Tokio async runtime, atomic operations</li> Testing:</strong> Comprehensive test suite with 100% Clippy compliance</li> </ul> Technical Achievements</h3> Lock-free hot path:</strong> ring buffers and object pools for microsecond latency</li> Zero-allocation operations:</strong> pre-allocated objects eliminate heap allocations in critical paths</li> Intelligent backpressure:</strong> emergency mode with probabilistic throttling</li> Memory safety:</strong> hard limits with emergency cleanup (512MB default)</li> Multithreaded scaling:</strong> 10 symbols × 3 channels = 30 concurrent streams</li> Financial precision:</strong> complete Decimal usage eliminates floating-point errors</li> </ul> Impact & Recognition</h3> Production-ready library for algorithmic trading systems</li> Comprehensive documentation with multiple demo applications</li> Zero-crash design through elimination of all panic points</li> HFT-grade performance optimisations for enterprise use</li> Open source contribution to Rust cryptocurrency ecosystem</li> </ul> About Me 2025-01-15T00:00:00+00:00 Julius Metodiev</h1> Software Architect</h2> I'm a passionate software architect with extensive experience in designing and building scalable systems. I specialize in creating robust, maintainable solutions that solve real-world problems.</p> Professional Summary</h2> With years of experience in software development and system architecture, I focus on:</p> System Design & Architecture</strong> - Designing scalable, maintainable software systems</li> Technical Leadership</strong> - Leading development teams and making strategic technical decisions</li> Problem Solving</strong> - Analyzing complex requirements and delivering effective solutions</li> Continuous Learning</strong> - Staying current with emerging technologies and best practices</li> </ul> Technical Expertise</h2> Core Technologies</h3> Languages:</strong> Go, Rust, Python, JavaScript, TypeScript, Java</li> Frontend:</strong> React, Vue.js, HTML5, CSS3, Tailwind CSS</li> Backend:</strong> Go microservices, Rust libraries, gRPC APIs, Node.js, Django</li> Databases:</strong> PostgreSQL with PostGIS, Qdrant vector database, MongoDB, Redis</li> </ul> Architecture & DevOps</h3> Architecture Patterns:</strong> Microservices (15+ services), Domain-Driven Design, Event-Driven Architecture</li> Messaging:</strong> NATS for high-performance inter-service communication, WebSocket protocols</li> Cloud Platforms:</strong> AWS, Azure, Google Cloud Platform</li> Containerization:</strong> Docker, Kubernetes with HA infrastructure</li> CI/CD:</strong> GitHub Actions, GitLab CI, Jenkins</li> </ul> AI & Specialized Technologies</h3> AI/ML:</strong> Custom compatibility algorithms, MBTI/Human Design systems</li> Vector Databases:</strong> Qdrant with specialized embeddings</li> Performance:</strong> Sub-100ms response times, 99.9% uptime systems</li> HFT Systems:</strong> Lock-free programming, microsecond latency optimization</li> Financial Tech:</strong> Protocol Buffers, real-time data processing (1,300+ msgs/sec)</li> Geospatial:</strong> PostGIS integration for location-based features</li> </ul> Tools & Methodologies</h3> Version Control:</strong> Git, GitHub, GitLab</li> Project Management:</strong> Agile, Scrum, Kanban</li> Monitoring:</strong> Prometheus, Grafana, ELK Stack, real-time alerting</li> Testing:</strong> Unit Testing, Integration Testing, TDD, load testing</li> </ul> What I Do</h2> I help organizations build better software by:</p> Architecting Solutions</strong> - Designed microservices platform serving 10,000+ users with 99.9% uptime</li> Performance Engineering</strong> - Achieved sub-100ms response times across distributed systems</li> AI Implementation</strong> - Built compatibility algorithms improving match accuracy by 40%</li> Team Leadership</strong> - Led development of 15+ microservices with modern tech stack</li> Technical Strategy</strong> - Strategic technology decisions for scalable, maintainable systems</li> </ul> Open Source & Community</h2> I actively contribute to the open source community:</p> rust-mexc-ws</strong>: Production-grade WebSocket client for MEXC exchange (Rust)</li> rust-binance</strong>: High-performance async client for Binance WebSocket API (Rust)</li> Cryptocurrency Libraries</strong>: Building HFT-ready libraries for algorithmic trading</li> Zero-unsafe Rust</strong>: Advocate for memory-safe systems programming</li> Performance Engineering</strong>: Lock-free algorithms and microsecond optimization</li> </ul> Interests</h2> When I'm not coding, I enjoy:</p> Contributing to open-source projects</li> Learning about new technologies and frameworks</li> Reading about software engineering best practices</li> Exploring high-frequency trading and financial technology</li> Experimenting with systems programming in Rust</li> </ul> Feel free to get in touch</a> if you'd like to discuss technology, collaborate on projects, or just have a chat about software development.</em></p> Contact 2025-01-15T00:00:00+00:00 Get In Touch</h1> I'm always interested in discussing new opportunities, collaborating on interesting projects, or just having a conversation about technology and software development.</p> Professional Networks</h2> LinkedIn:</strong> Connect with me on LinkedIn</a></p> GitLab:</strong> View my code and projects</a></p> Twitter/X:</strong> @JMetodiev</a></p> go-collector 2024-06-01T00:00:00+00:00 High-performance Go service for collecting cryptocurrency order book data.</p> Tech:</strong> Go, Kafka / Redpanda, ClickHouse, Prometheus, WebSocket</li> Purpose:</strong> Real-time order book data collection and analysis pipeline</li> Features:</strong> Binance protocol compliance, automatic sequence validation, metrics monitoring</li> Architecture:</strong> WebSocket → Kafka → ClickHouse with health checks and Grafana dashboards</li> </ul> rust-binance 2024-01-01T00:00:00+00:00 High-performance, asynchronous Rust client for Binance WebSocket API.</p> Tech:</strong> Rust, Tokio, FlatBuffers, WebSocket protocols</li> Purpose:</strong> Real-time cryptocurrency market data processing</li> Features:</strong> Zero-copy serialisation, intelligent reconnection, combined streams</li> Focus:</strong> HFT-ready performance with type-safe API design</li> </ul> Equal Dating 2018-01-01T00:00:00+00:00 Role:</strong> Software Architect / Lead Developer Timeline:</strong> 2018 — Present (7 years of research and development) Status:</strong> Production — Serving 10,000+ users</p> Architecture & Scale</h3> Microservices platform with 15+ services achieving 99.9% uptime</li> Sub-100ms response times across all endpoints</li> High-availability Kubernetes infrastructure</li> NATS messaging system for real-time communication</li> PostgreSQL database with 150+ tables and PostGIS integration</li> Automated backup strategies and disaster recovery</li> </ul> Key Features</h3> AI-powered compatibility systems using MBTI / Human Design algorithms</li> Progressive photo reveal through conversation points system</li> Gamified dating experience with achievements and leveling</li> Vector database (Qdrant) with specialised embeddings for compatibility</li> No swiping — focus on meaningful conversations first</li> Message scoring system that rewards quality interactions</li> </ul> Technical Stack</h3> Backend:</strong> Go microservices, Rust services, gRPC APIs</li> Messaging:</strong> NATS for inter-service communication</li> Database:</strong> PostgreSQL with PostGIS, Qdrant vector database</li> Infrastructure:</strong> Kubernetes, Docker, high-availability setup</li> AI / ML:</strong> Custom compatibility algorithms and embeddings</li> Monitoring:</strong> Real-time performance tracking and alerting</li> </ul> Key Achievements</h3> Improved match accuracy by 40% through AI-powered algorithms</li> Architected scalable platform serving 10,000+ concurrent users</li> Eliminated superficial swiping culture in dating apps</li> 7-year research foundation for compatibility science</li> Built high-performance vector search for advanced compatibility assessment</li> </ul> Company: Resistance Group</strong></p>