Mercury, our trading system, has undergone a significant architectural transformation from direct service dependencies to an event-driven architecture. This migration has improved the system's maintainability, testability, and extensibility.
Our Mercury trading system has grown organically over time, leading to intertwined services, duplicated code, and complex state management. This document outlines a strategic approach to refactoring key components to improve maintainability, testability, and performance.
In the vast digital cosmos of trading, ancient forces have been reborn. This is the tale of how celestial beings from across mythologies came together to form the divine pantheon that powers our trading system.
Long before algorithms ruled the markets, the gods watched over traders and their fortunes. As the digital age dawned, these ancient deities found new purpose in our trading system, each bringing their divine powers to create a perfect harmony of celestial trading intelligence.
Supporting the entire trading universe on his shoulders stands ATLAS, the Titan condemned by Zeus to hold up the heavens for eternity. His strength and endurance are unmatched among immortals.
In our trading pantheon, ATLAS serves as the system that binds all components together:
ATLAS's eternal vigilance prevents chaos, maintaining the structured universe where trading can flourish.
After observing our development flow and documentation challenges, we're implementing key architectural improvements to make Mercury's development more maintainable and clear. This post documents these decisions for future reference.
When evaluating approaches for bullshit detection in LLM outputs, we need clear criteria that prioritize practical value over theoretical elegance. This post outlines key criteria for evaluating different approaches.
Today, I encountered a classic dependency injection issue while integrating a new tournament system with artifacts tracking in our Mercury Bot project. The error was subtle but instructive:
[Nest] 2991604 - 02/03/2025, 6:01:58 PM ERROR [ExceptionHandler] Cannot read properties of undefined (reading 'get')
TypeError: Cannot read properties of undefined (reading 'get')
Types are the backbone of any TypeScript project, but as the codebase grows, they can become scattered and hard to maintain. Here's a practical guide on organizing types, with a real-world example from Mercury Bot.
Keep types close to their domain logic, organized by feature. This approach makes it easy to find related types and maintains a clear connection between types and their usage.
src/
├── market-ranking/
│ ├── types/
│ │ ├── state.types.ts
│ │ ├── config.types.ts
│ │ └── index.ts
When building a TypeScript project, type declarations are your first line of defense against bugs and maintainability issues. However, certain type declaration patterns can actually work against you, creating technical debt and making your codebase harder to maintain. Let's explore 10 specific anti-patterns we've identified in our analysis of real-world TypeScript projects.
In any growing project, there comes a time when the initial architecture starts showing signs of strain. As features expand and requirements evolve, what once seemed like a clear structure can become muddled. Today, I want to share our journey of refactoring TON Arcana, focusing on creating a more cohesive, domain-driven architecture.
Here are 10 elegant improvements we're implementing to make our codebase cleaner, more maintainable, and better aligned with domain concepts.
Guide on how to use architectural archaeology to uncover implicit architectural decisions in my projects.