标签：#design

"A Stack isn't designed to store data. It's designed to make the most recent piece of work the easiest to access." In the previous article, we discovered a new kind of design problem. Some systems don't need to find the fastest item. Some don't need to process tasks in arrival order. Instead, they need to work with whatever happened most recently . That's exactly the problem a Stack solves. In this article, we'll understand how a Stack works and why its behavior appears naturally in many software systems. Imagine a Stack of Plates Think about a stack of dinner plates. Plate 4 ────────── Plate 3 ────────── Plate 2 ────────── Plate 1 ────────── When you need a plate, which one do you take? The one on the top. You don't pull out the bottom plate. Likewise, when placing a new plate, you put it on top. This simple rule defines the behavior of a Stack. What Is a Stack? A Stack is a data structure where both insertion and removal happen from the same end. The last item added is always the first one removed. This behavior is called LIFO (Last In, First Out). Push A ↓ Push B ↓ Push C ↓ Pop ↓ C Notice something important. A Stack isn't trying to preserve arrival order like a Queue. Instead, it preserves recency . The newest item is always the easiest to access. Every Data Structure Solves a Different Design Problem By now, we've seen several data structures, each answering a different question. A HashMap asks: Where is this object? A Heap asks: Which item has the highest priority? A Queue asks: Which task has been waiting the longest? A Stack asks: What happened most recently? Choosing the right data structure begins with identifying which of these questions your system needs to answer. Push and Pop Stacks are built around two simple operations. Push Adding a new item. Before Top ↓ B ↓ A Push C After Top ↓ C ↓ B ↓ A Pop Removing the most recent item. Before Top ↓ C ↓ B ↓ A Pop After Top ↓ B ↓ A Only the top item is removed. Everything below remains untouched. Real-World Examp

Chris Richardson discusses leveraging Team Topologies and internal platforms to accelerate microservices delivery. He explains six key platform patterns - from security and observability to build and deployment - and shares strategies for minimizing cognitive load on stream-aligned teams while avoiding common platform engineering pitfalls. By Chris Richardson

Author: Skydu Summary: A form engine may look like the most basic capability in a low-code platform, but it is really the entry point for business modeling, data structure, permissions, workflows, and future AI understanding. Opening In the previous post, I wrote about why INFORMAT is not meant to be only a low-code tool. Starting from this post, I want to go into specific modules. The first module I want to write about is the form engine. The reason is simple: in a low-code platform, forms look basic, but a form is not just a page. Many enterprise business systems begin with a form. Customer registration, contract approval, project initiation, purchase requests, inventory receiving, equipment inspections, and production reporting are all, at their core, ways to collect, organize, and move business data. So a form engine is not about dragging a few input boxes onto a canvas. It is the entry point for the platform's business modeling capability. The initial requirement looked simple Before building the form engine, my most straightforward idea was this: users should be able to create business forms, configure fields, and let the system automatically generate data-entry pages and data lists. That idea does not sound complicated. A form name, a group of fields, a save button, and a data list seem like enough. But once implementation begins, a series of questions appear quickly. What field types should exist? Can fields be grouped? Can fields depend on each other? Should data be validated? Should a workflow be triggered after submission? Can different people see different fields? How will form data be used by reports, automation, and AI? When these questions stack together, the form engine stops being only a frontend component. It becomes a core module that connects the data model, permission system, workflow system, and automation system. A form is not a page, but a business model I gradually became more certain of one judgment: forms in a low-code platform should not

Cookie banners are still a nuisance. GDPR, the European privacy law, seems like a perfect example of...

A generated image looks finished until review starts. Someone approves the first version. Someone else crops it. A branded copy goes out. Another edit changes the prompt. A week later, the useful question is simple: which prompt, model, seed, size, parent image, and publishing settings produced the version on screen? In a content studio, I put those answers in the PostgreSQL row that stores the image. Logs explain what happened during a run, then rotate away. Object storage keeps the bytes and forgets why they exist. The row is the only one of the three that survives edits, review, and publishing. 1. The row is the receipt The table in apps/api/src/database/init-ai-images-table.js treats generated and edited images as one record type. An original image gets its own row. An edit gets another row, with original_image_id pointing back to the parent. CREATE TABLE IF NOT EXISTS ai_generated_images ( id SERIAL PRIMARY KEY , image_url TEXT NOT NULL , -- what produced it prompt TEXT NOT NULL , model VARCHAR ( 100 ) DEFAULT 'fal-ai/imagen4' , model_version VARCHAR ( 100 ), seed BIGINT , width INTEGER , height INTEGER , -- how it derives from another row is_edited BOOLEAN DEFAULT FALSE , original_image_id INTEGER REFERENCES ai_generated_images ( id ), edit_prompt TEXT , edit_strength DECIMAL ( 3 , 2 ), -- what actually shipped branded_url TEXT , branding_options JSONB , metadata JSONB , tags TEXT [], created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); That self-reference is the design choice. It makes the image table append-only-ish: new variants are inserted as new rows instead of overwriting the earlier state. The cost is more rows and more discipline at write time. The benefit is editable history that product screens and debugging queries can follow. flowchart TD original["Original row: prompt, model, seed, dimensions"] editA["Edited child: edit_prompt, edit_strength, edit_steps"] editB["Edited child: edit_prompt, edit_guidance_scale"] brandedA["Branded output: branded_url,

User segmentation requirement Imagine you need to send a push notification to users who satisfy all of the following conditions: Push notification is enabled User is a VIP Active within the last 30 days Following the Voucher Hot category The traditional approach is to query multiple tables: SELECT DISTINCT u . id FROM users u JOIN user_configs c ON c . user_id = u . id JOIN devices d ON d . user_id = u . id JOIN follows f ON f . user_id = u . id WHERE c . push_optin = 1 AND c . mute = 0 AND d . fcm_token IS NOT NULL AND f . category = 'voucher_hot' AND u . last_active >= NOW () - INTERVAL 30 DAY ; As your user base grows into the millions, every campaign requires joining multiple large tables, filtering millions of records, and repeatedly computing the same audience. Query latency increases significantly, making real-time segmentation increasingly difficult. A Different Approach Instead of querying the database every time, we precompute each boolean attribute as a bitmap. Think of a bitmap as a huge array containing only 0 and 1, where the index corresponds to the user ID. For example, a bitmap representing whether a user has enabled push notifications: User ID : 0 1 2 3 4 5 6 7 Bitmap : 1 0 1 1 0 0 1 1 To check whether user 123 has enabled notifications, simply read bit 123. 1 → enabled 0 → disabled Each bitmap represents exactly one boolean property: bitmap:push_optin bitmap:vip bitmap:active30 bitmap:follow:voucher_hot Memory Usage Bitmap is extremely memory efficient. Each user requires only one bit. For 1 million users: 1.000.000 bits ~ 125.000 bytes ~ 122 KB That means every segment only consumes about 122 KB of Redis memory. Even 100 different segments require only around 12 MB . Finding Intersections Suppose you want all users that are: VIP AND Push Opt-in AND Active30 AND Following Voucher Hot Redis can calculate the result with a single command: BITOP AND result vip push_optin active30 follow_voucher_hot Need the number of matched users? BITCOUNT result No

Why do simple features suddenly require cross-team negotiations? In this article, explore how boundary drift quietly destroys change locality and increases cognitive load across teams. Learn practical sociotechnical strategies - redistributing mechanics, exposing essential policy, and rehearsing exception paths - to restore domain boundaries and enable a truly evolutionary software architecture. By Michael Fischer, Nicholas Lawrence, Monica Karekar

Embabel has reached its 1.0 release, providing a framework for AI agents on Java It allows Java and Kotlin developers to define agents as typed domain objects. Built on Spring AI, Embabel supports multiple model providers and combines planning with predefined state machines, offering flexibility for agent workflows. By Erik Costlow

Every design team eventually ships a beautiful off-white, off-blue, or off-anything background… and then opens the app on a $120 phone and watches it turn dirty gray . Same hex, same build. This post explains why, and gives you a small formula to convert any tint you've chosen into one that survives budget panels. Why subtle tints die on cheap screens Four panel-level failure modes, all common in the budget tier: 1. Weak gamut coverage. Entry-level LCDs cover only a fraction of sRGB — independent panel measurements routinely land in the 55–70% range, with large per-color error. A low-chroma tint simply doesn't have the budget to survive that compression. 2. Cold white points. sRGB assumes a D65 white (6500K). Budget modules commonly ship visibly cooler — high-6000s to 9000K+ — because blue-ish whites look "brighter" in a store. That blue cast is spread across the entire grayscale, and its magnitude is comparable to a subtle warm tint. Net result: the panel can cancel your background color outright. 3. Stretched gamuts on budget AMOLED. The opposite failure: "vivid" default modes stretch sRGB content across the panel's wider native gamut. Your quiet tint renders at roughly double saturation and suddenly has an opinion. 4. Banding. Many cheap panels are 6-bit + FRC. Soft near-white gradients develop visible steps, which makes barely-different surface colors look like rendering bugs. The 4% rule You don't need a colorimeter to know if you're at risk. Use channel spread — the distance between your highest and lowest RGB channel — as a chroma proxy: spread = max(R, G, B) − min(R, G, B) If spread is under ~10 of 255 (≈4%) , your tint is inside a cheap panel's error bar. It may render as intended, as gray, or as tinted the other direction — you don't get a vote. (Quick check on any hex: two outer pairs of digits within ~0x0A of each other = you're in the danger zone.) Why 4%? Because that's the same order of magnitude as the grayscale tint produced by a few-hundred-kelvin

Most of the engineers consider documentation as an after-thought; a README on a finished system written in the final 20 minutes before a PR gets merged. That's the wrong way to do this relationship. Documentation is not a description of architecture. It is part of the architecture, and marking it as separate is the cause of so many rotting systems, which still pass all tests. The compiler doesn't care, your team does It could be a consistent codebase and yet it be undocumented garbage from the point of view of anybody who didn't write it. Only one sort of correctness is enforced by the compiler (or interpreter): does this code perform the operation that the instructions say it performs. It doesn't weigh in on why a specific table contains a deleted_at column, versus a hard delete, or why a service tries 3 times with exponential back-off, versus 5 times with a fixed interval. Those decisions include constraints that are not apparent in the diff, regulatory, historical, or performance. If these are only in the mind of the programmer who wrote them, the actual architecture is partially undocumented, and these constraints will be breached as soon as someone else messes with the code when it is under a tight deadline. Architecture is not only the shape of your services and schemas, it's the set of decisions and constraints that shape stayed within. Undocumented constraints are like walls that we don't see, or know about. They are walked through without anyone knowing they exist, and one of the assumed conditions is broken at a time. Documentation as a design artifact, not a report Good documentation should be done prior to and/or in the midst of implementation, not after. When writing a design doc that explicitly states the problem, the options you considered, the one you selected, and the tradeoffs you made, you are actually doing real design work, you are making mistakes in your thinking process that would only become apparent during production. There have been more ti

"A Heap doesn't stay useful because everything is sorted. It stays useful because every parent follows one simple rule." In the previous article, we learned that a Heap is built for continuous decision-making. Whether it's assigning the nearest driver, scheduling the next process, or selecting the most urgent support ticket, the system always needs one thing: The next best candidate But that raises an interesting question. How can a Heap always know the best candidate without sorting everything? The answer lies in one simple rule: The Heap Property. This single rule is what gives a Heap its power. The Biggest Misconception About Heaps Many beginners imagine a Heap like this. 100 95 90 82 76 64 51 Everything perfectly sorted. It feels logical. If the largest element should always come first, shouldn't every element be arranged in order? Surprisingly, no. A Heap solves a much smaller problem. It only guarantees that the best element is always easy to reach . Everything else only needs to follow one simple relationship. Imagine a Company Hierarchy Think about the structure of a company. CEO ↓ Engineering Director ↓ Engineering Manager ↓ Software Engineer The CEO doesn't directly manage every employee. Instead, each manager is responsible only for the people immediately below them. The entire organization works because every manager fulfills their local responsibility. A Heap works in a very similar way. Every node only needs to maintain the correct relationship with its immediate children. It doesn't need to know about every other node in the structure. The Heap Property Let's look at a Max Heap. 100 / \ 90 80 / \ / \ 75 60 70 50 Notice the pattern. Every parent has a value greater than or equal to its children. That's the Heap Property. Parent ≥ Children That's it. There is no rule saying that every node must be greater than every other node in the Heap. Only the parent-child relationship matters. What About a Min Heap? Some systems want the smallest value first. For

"A HashMap helps you find what you already know. A Heap helps you decide what should happen next." In the previous article, we discovered that not every software problem is about finding a specific object. Sometimes, the system already knows exactly what it's looking for. Find User ID = 1024 ↓ Return User Other times, the system doesn't know the answer in advance. Instead, it has to repeatedly answer questions like: Which task should run next? Which driver should be assigned? Which customer should be served first? Which alert is the most critical? These are fundamentally different problems. Instead of retrieving an object, the system is making a decision. This is where a Heap comes in. A Heap Is Built for Decisions, Not Searches Imagine you're managing a hospital emergency room. Patients keep arriving throughout the day. Patient A Minor Injury Patient B Heart Attack Patient C Broken Arm Patient D High Fever Should doctors treat patients in the order they arrived? Probably not. Instead, they ask one question. Who needs treatment first? Notice something important. The hospital isn't searching for a particular patient. It's choosing the highest-priority patient. A Heap is designed for exactly this kind of problem. A Different Way of Thinking When beginners hear "data structure," they often think about storing data. Experienced engineers think differently. They ask: "What operation does my system perform repeatedly?" If the answer is: Find User Find Order Find Product that's a lookup problem. But if the answer is: Choose Highest Priority Choose Nearest Driver Choose Earliest Deadline that's a decision problem. A Heap is optimized for continuous decision-making. What Exactly Is a Heap? A Heap is a data structure that keeps the most important element immediately available. Depending on the system, "most important" can mean different things. For example: Highest priority Lowest cost Earliest deadline Highest score Closest driver Most urgent ticket The Heap doesn't decide w

"Finding something quickly and finding the best thing quickly are two completely different engineering problems." So far in this series, we've explored one of the most common behaviours in software systems: Fast lookup. Whenever a system already knows what it's looking for—a User ID, Product ID, Order ID or Session ID—a HashMap becomes an excellent choice. But not every software problem works this way. Imagine you're building a ride-sharing application. A rider requests a cab. The system doesn't already know which driver to assign. Instead, it must answer a different question: "Out of all available drivers, who is the best choice?" Now consider a task scheduler. Hundreds of jobs are waiting to run. The scheduler doesn't ask: "Find Job #123." It asks: "Which job should run next?" Or imagine a gaming platform. Thousands of players are competing. Nobody asks: "Find Player ID 1057." Instead, users ask: "Who are the top 10 players?" These problems are fundamentally different from fast lookup. They're not about finding a specific object . They're about finding the best object according to some priority. This shift in thinking introduces another important design behaviour. Fast Lookup vs Best Selection Let's compare two different requirements. Requirement 1 Customer ID = 1052 ↓ Retrieve Customer The system already knows exactly what it needs. The challenge is retrieving it efficiently. Requirement 2 Available Drivers ↓ Find Nearest Driver ↓ Assign Ride The system doesn't know the answer yet. It must compare multiple candidates before making a decision. These two behaviours may look similar. In reality, they solve completely different engineering problems. Every Software System Doesn't Search the Same Way Consider these questions. Find Order #50231 versus Find the highest priority order. Or: Retrieve Product ID = P1042 versus Recommend the most popular product. Or: Find Employee ID = 2107 versus Find the employee with the highest sales this month. The first question always

This article describes an anonymized enterprise implementation. Company names, internal domains, repository identifiers, ticket numbers, and proprietary control names have been intentionally removed or generalized. Multi-factor authentication is often described as a login problem: enter a password, receive a code, confirm identity. That model was not enough for the system described in this case study. The product ran in an in-store environment where the same tablet could be used by several people during a transaction: an employee initiating the process; a manager approving or supporting it; a customer reviewing and signing on their own device. The challenge was not simply to prove that a user knew a six-digit code. We needed to create a secure, short-lived handoff between a shared in-store session and the customer’s personal phone, without leaking the downstream signing session or allowing multiple devices to claim the same transaction. This post explains the architecture, the security model, the trade-offs, and the production practices behind that platform. The actual problem: secure device handoff The workflow started on a shared tablet. At a certain point, the customer needed to continue part of the process on their own phone. The platform therefore had to answer several questions: How does the phone prove that it belongs to the customer currently standing in front of the employee? How does the shared tablet know that the correct phone claimed the correct session? What happens if the QR code is scanned twice? How do we prevent session identifiers and tokens from appearing in URLs, browser history, logs, or referrer headers? How do we notify the phone immediately when verification succeeds? How do we ensure that a single-use signing URL is never exposed before verification? Those constraints turned a seemingly small MFA feature into a distributed-system problem involving identity, real-time communication, concurrency, edge delivery, infrastructure, and operational

Introduction to Clean Architecture Clean architecture, a software design philosophy championed by the renowned Robert C. Martin (Uncle Bob), has revolutionized the way developers approach system design. By prioritizing the separation of concerns and promoting independence From frameworks, user interfaces, and databases, clean architecture empowers developers to build robust, maintainable, and scalable systems. This design approach is not just a theoretical concept, but a practical solution for real-world problems. In this guide, we'll explore the principles of clean architecture and provide a step-by-step roadmap for implementing it in your own projects, so you can get started with clean architecture and Unlock its full potential. Independent of Frameworks: Your business logic shouldn't depend on external libraries Testable: Business rules can be tested without UI, database, or external services Independent of UI: You can swap web UI for console UI without changing business logic Independent of Database: You can swap SQL Server for MongoDB without changing business rules Independent of External Services: Business rules don't know about external services Core Principles Clean Architecture organizes code into concentric circles, with dependencies pointing inward: 1. Entities (Inner Circle) These are the business objects of your application. They contain enterprise-wide business rules and are the most stable part of your system. public class User { public string Id { get ; set ; } public string Email { get ; set ; } public string Name { get ; set ; } public bool IsValid () { return ! string . IsNullOrEmpty ( Email ) && Email . Contains ( "@" ); } } 2. Use Cases (Application Layer) This layer contains application-specific business rules. It orchestrates the flow of data to and From entities. public class CreateUserUseCase { private readonly IUserRepository _repository ; public async Task < User > Execute ( CreateUserRequest request ) { var user = new User { Email = requ

Designing AI Systems That Outlive Today's Models If there's one lesson this series has taught me, it's this: Don't build your application around a model. Build it around a capability. That might sound like a small distinction. It isn't. Because models change. Constantly. A few months ago everyone was talking about GPT-4. Then Claude. Then Gemini. Then DeepSeek. Then Qwen. By the time you're reading this, there's probably another model making headlines. Imagine rewriting your application every time that happens. That's not innovation. That's technical debt. One mistake I see quite often is developers tightly coupling their applications to one provider. Your business logic knows it's talking to GPT-4. Your prompts are written specifically for GPT-4. Your output parsing assumes GPT-4. Your error handling assumes GPT-4. Now imagine your company decides to switch providers. What should have been a configuration change suddenly becomes weeks of refactoring. That's avoidable. Your application shouldn't know who answered the request. It should only know that the capability it asked for was delivered. Summarize this document. Generate this code. Classify this text. Translate this paragraph. Those are capabilities. The provider is simply an implementation detail. One thing I regret not doing earlier was versioning prompts. Most developers version everything else. Source code. Database migrations. Infrastructure. Configuration. Then prompts end up looking like this: typescript id = " a8fj21 " const prompt = " You are a helpful assistant... " ; Three months later someone tweaks a sentence. Responses change. Nobody knows why. Sound familiar? Prompts deserve the same engineering discipline as code. Version them. Review them. Document why changes were made. Roll them back when needed. Prompt engineering isn't magic. It's software development. Imagine you've found a brand-new reasoning model that performs better than your current one. Do you deploy it to every user immediately? Pro

Avi Schiffmann has a new version of his controversial AI companion. It’s more expensive, and you can’t change its personality.

"The real magic of a HashMap isn't that it stores data. It's that it knows where to start looking." In the previous article, we learned that a HashMap organises information around unique keys. Instead of searching every stored object one by one, it uses the key to retrieve information quickly. That naturally raises another question. "If millions of objects are stored inside a HashMap, how does it know where to begin?" Surely it isn't remembering the location of every object individually. The answer lies in one of the most important ideas in computer science: Hashing. Don't worry if the word sounds intimidating. Despite its name, the idea behind hashing is surprisingly simple. Imagine a Huge Apartment Building Suppose you're visiting a friend who lives in a building with 5,000 apartments. If nobody told you the apartment number, what would you do? Probably something like this. Apartment 1 ↓ Apartment 2 ↓ Apartment 3 ↓ ... ↓ Friend's Apartment That would take a long time. Now imagine your friend simply tells you: Apartment 1842 Suddenly, you don't search the building. You walk directly to Apartment 1842. The apartment number isn't your friend. It simply tells you where to begin. Hashing works in exactly the same way. Keys Need Locations Suppose our application stores customers. Customer ID → Customer 1001 → Alice 1002 → Bob 1003 → Charlie 1004 → David The system needs a way to answer one question. "Where should Customer 1002 be stored?" Searching every location first would defeat the purpose of using a HashMap. Instead, the system calculates where that key should go. Notice something important. It doesn't compare Customer 1002 against every other customer. It calculates a location directly. Think of a School Locker System Imagine a school with thousands of students. Every student receives a locker. Student ID ↓ Locker Number ↓ Locker Students don't spend every morning searching hundreds of lockers. Their Student ID determines where they should go. The locker number is

Not long ago, designers relied on AI mostly for generating images or experimenting with quick...

"The best software engineers don't begin by choosing data structures. They begin by understanding what the system needs to do." In the previous article, we learned that data structures never stopped being important after DSA. Their role simply changed. During coding interviews, we often ask ourselves: "Which data structure will solve this problem efficiently?" In Low-Level Design, experienced engineers ask a different question: "What behaviour should this system optimise?" At first glance, these questions sound similar. In reality, they lead to completely different ways of thinking. This article is about understanding why behaviour—not implementation—is where every good design begins. Why Beginners Often Think About Data Structures Too Early Imagine someone asks you to design an online food delivery platform. Many beginners immediately start thinking: Should I use a HashMap? Will I need a Queue? Should I store everything in a Tree? Would a Graph be useful? These aren't bad questions. They're simply being asked too early. Before choosing any data structure, we need to understand what the system is actually expected to do. Software engineering isn't about selecting tools first. It's about understanding problems first. Every Software System Is Really a Collection of Behaviours Let's consider a food delivery application. From a user's perspective, it looks like this. Customer Places Order │ Restaurant Accepts │ Assign Delivery Partner │ Track Delivery │ Order Delivered It looks like one workflow. But an engineer sees something very different. Each step represents a different behaviour. Let's break them apart. Behaviour 1 — Retrieve Existing Information A customer opens an order they placed yesterday. Customer ↓ Order ID ↓ Retrieve Order The system already knows exactly which order it needs. The challenge is retrieving it quickly. Behaviour 2 — Choose the Best Candidate A restaurant has multiple delivery partners nearby. Available Drivers ↓ Choose Best Driver ↓ Assign Ri