# Anis Messas **Full Stack Developer** From shaping the problem and architecture to establishing the codebase, building the system, verifying behavior, provisioning infrastructure, automating delivery, operating production, and improving it through evidence. # About ## I engineer software as a complete system. From shaping the problem and architecture to establishing the codebase, building the system, verifying behavior, provisioning infrastructure, automating delivery, operating production, and improving it through evidence. - SYSTEMS THINKING - PRODUCT OWNERSHIP - SOFTWARE ENGINEERING ### Engineering lifecycle #### DISCOVER Frame the problem, understand the domain, and make constraints explicit. - Problem framing - Domain discovery - Constraints #### DESIGN / ARCHITECTURE Define system boundaries and make deliberate engineering trade-offs. - System boundaries - Trade-offs - Architecture #### INITIALIZE Establish the repository and engineering environment without unnecessary friction. - Repository setup - Environment #### MODEL Shape the domain, data, contracts, and APIs before implementation hardens them. - Domain modeling - Data modeling - Contracts - APIs #### BUILD Implement the product across frontend, backend, services, data, and events. - Frontend - Backend - Services - Data - Events #### VERIFY Prove behavior with testing, quality controls, and security checks. - Testing - Quality - Security #### PROVISION Create the cloud, infrastructure-as-code, and runtime foundation the product needs. - Cloud - Infrastructure as code - Runtime #### DELIVER Automate CI/CD, release, and deployment so change can move safely to users. - CI/CD - Release - Deployment #### OPERATE Own availability, resilience, runtime behavior, and recovery in production. - Availability - Resilience - Runtime - Recovery #### OBSERVE Understand system behavior, surface constraints, and reduce blockers. - Behavior - Evidence - Reduce blockers #### EVOLVE Use evidence to improve the product, adapt to change, and reduce blockers. - Refactor - Scale - Simplify - Redesign - Reduce blockers ### Impact metrics #### 32.3× — fewer API/network requests Request reduction delivered in a large TypeScript AI application. #### 2–7× — faster Speed improvement increased with collection size in the same TypeScript AI application. #### 2× — throughput Concurrency-safe architecture changes doubled throughput without data inconsistencies. #### 40% — faster deployment Infrastructure automation shortened deployment time while reducing manual configuration errors. #### 50% — fewer runtime errors Pre-deployment graph validation detected invalid workflow cycles before release. ### Engineering principles #### Understand before adding complexity Model the problem, system, and constraints before increasing architectural complexity. #### Measure before optimizing Use evidence to identify actual bottlenecks and validate improvements. #### Prefer the appropriate solution Choose the approach that best fits the problem and its constraints. #### Design for the lifecycle Software should be testable, deployable, observable, maintainable, and evolvable. #### Treat boundaries seriously Clear system, package, and service responsibilities reduce coupling and accidental complexity. #### Automate repeatable work Build, test, infrastructure, deployment, and maintenance should be reproducible. ### Current direction #### DISTRIBUTED SYSTEMS Systems where correctness and throughput depend on explicit concurrency, consistency, messaging, and resilience decisions. - CONCURRENCY - CONSISTENCY - MESSAGING - RESILIENCE - THROUGHPUT #### PERFORMANCE ENGINEERING Evidence-led work on latency, bottlenecks, and resource or network efficiency. - PROFILING - LATENCY - BOTTLENECKS - RESOURCE EFFICIENCY #### APPLIED AI AI-enabled software where model capability is one component inside a deliberate product architecture. - HYBRID SYSTEMS - PROVIDERS - ORCHESTRATION - PRODUCT INTEGRATION #### DEVELOPER / PLATFORM ENGINEERING Tooling and delivery systems that make engineering environments reproducible and productive. - MONOREPOS - INTERNAL TOOLING - BUILD SYSTEMS - CI/CD #### PRODUCT ENGINEERING Cross-layer ownership from architecture through operation, with measurable technical outcomes. - CROSS-LAYER OWNERSHIP - ARCHITECTURE → OPERATION - MEASURABLE OUTCOMES # Technical Skills ## Programming languages - **JAVA:** DISTRIBUTED SYSTEMS, MICROSERVICES, EVENT-DRIVEN ARCHITECTURE - **TYPESCRIPT:** FRONTEND, BACKEND, FULL STACK - **PYTHON:** PROTOTYPING, AUTOMATION, AI / COMPUTER VISION ## Data layer - POSTGRESQL - MYSQL - MSSQL - MONGODB - NEO4J ## Application development ### FRONTEND Component-driven web applications, responsive interfaces, and modern TypeScript tooling. - **REACT:** TypeScript · Vite - **ANGULAR:** TypeScript · SPA **FOUNDATION & STYLING** - HTML - CSS - SASS - TAILWIND - BOOTSTRAP - VITE ### BACKEND — JAVA / SPRING Java application services, persistence layers, and APIs built around Spring. - **SPRING BOOT:** Java · REST - **HIBERNATE / JPA:** Persistence · Data **FRAMEWORKS & APIs** - SPRING FRAMEWORK - REST API - GRAPHQL ### BACKEND — TYPESCRIPT / NODE.JS TypeScript backend services, APIs, and serverless workloads across Node.js and cloud functions. - **NODE.JS:** TypeScript · Services - **SERVERLESS:** Azure Functions · AWS Lambda **SERVERLESS & APIs** - AZURE FUNCTIONS - AWS LAMBDA - REST API - GRAPHQL ### BACKEND — PYTHON Python services, automation, and prototyping used across application workflows and integrations. - **PYTHON SERVICES:** APIs · Automation - **PROTOTYPING:** Integration · Tooling **FRAMEWORKS & APIs** - DJANGO - FAST API ## DevOps ### CI / CD Build, test, and delivery automation across different project environments. - **Technologies:** GITHUB ACTIONS, AZURE PIPELINES, JENKINS ### CONTAINERS Repeatable application packaging from local development to deployment targets. - **Technologies:** DOCKER ### ORCHESTRATION Container deployment, configuration, and lifecycle management. - **Technologies:** KUBERNETES, HELM ### CLOUD Cloud environments used for application hosting, infrastructure, and delivery. - **Technologies:** AWS, AZURE, GOOGLE CLOUD, ORACLE CLOUD ### Foundations - **INFRASTRUCTURE AS CODE:** TERRAFORM, PULUMI, BICEP - **OPERATING ENVIRONMENT:** LINUX ## Architecture ### MICROSERVICES Service boundaries, independent responsibilities, and distributed application flows. ### EVENT-DRIVEN Asynchronous communication and event-based coordination between components. ### TRANSACTIONAL SYSTEMS Consistency, state transitions, and safe concurrent updates. ## Messaging - KAFKA - RABBITMQ ## Performance - MULTITHREADING - CACHING - RATE LIMITING - HIGH AVAILABILITY - LOAD BALANCING - PERFORMANCE OPTIMIZATION ## Security ### IDENTITY Standards and flows used to establish user or service identity. - **Technologies:** OAUTH2, OPENID CONNECT ### TOKEN Token-based transport of identity, claims, and authorization context. - **Technologies:** JWT ### AUTHORIZATION Role and permission checks that decide what an authenticated identity can access. - **Technologies:** RBAC ### APPLICATION PROTECTION Traffic controls that protect services and help preserve availability under load. - **Technologies:** RATE LIMITING ## Engineering disciplines ### COMPUTER SCIENCE Core problem-solving foundations used across application and systems work. - ALGORITHMS - DATA STRUCTURES - COMPETITIVE PROGRAMMING ### PROBLEM SOLVING Turning complex constraints into efficient and maintainable solutions. - ALGORITHM DESIGN - OPTIMIZATION - PROBLEM DECOMPOSITION ### SOFTWARE DESIGN Structuring code around clear responsibilities, reusable abstractions, and maintainable behavior. - OOP - DESIGN PATTERNS ### TESTING Verification practices used to keep changes predictable and protect system behavior. - TDD - UNIT TESTING - INTEGRATION TESTING ## AI workflow ### COMPUTER VISION Image processing and visual analysis used to extract structure, features, and useful signals from visual data. - **Technologies:** OPENCV ### MODELS & LEARNING Neural-network concepts and model workflows used when working with learned representations and AI systems. - **Technologies:** NEURAL NETWORKS ### AI PLATFORMS Managed AI services and provider APIs used to bring model capabilities into production applications. - **Technologies:** OPENAI API, AZURE OPENAI, VERTEX AI, AWS BEDROCK ### APPLICATION TOOLING Application-layer tooling used to connect model capabilities with workflows, context, and surrounding software. - **Technologies:** LANGCHAIN # Selected Work ## Engineering metrics - **32.3×** — FEWER REQUESTS - **2–7×** — FASTER - **UP TO ≈100×** — SMALLER PERSISTED PERMISSION STATE - **2×** — THROUGHPUT ## Engineering cases ### 01 — Reducing Network Amplification **ID:** network-amplification **Domain:** Performance Engineering Reduced request amplification in a large TypeScript/React AI workflow, cutting API/network requests by 32.3× and making the measured operation 2×–7× faster as collection size increased. **Type:** Application performance - **Concerns:** request amplification, response time, network load - **Stack:** TypeScript, React #### Metrics - **32.3×** — FEWER API/NETWORK REQUESTS - **2–7×** — FASTER BY COLLECTION SIZE #### Engineering reasoning ##### CONTEXT A large TypeScript AI application processed collection-oriented workflows whose API and network activity increased substantially with collection size. ##### PROBLEM The measured workflow amplified network and processing work across multiple stages as collections grew. The pressure was distributed through the flow rather than coming from one isolated unnecessary request. ##### CONSTRAINTS The optimization had to preserve existing workflow behavior while reducing unnecessary network activity and remaining stable as collection size increased. ##### DECISION Decompose the amplification problem into smaller pressure points, optimize them independently, and progressively coordinate the resulting work through one controlled end-to-end flow. ##### TRADE-OFF The optimized flow required more deliberate coordination than the original path, but it prevented improvements at one stage from simply shifting pressure elsewhere in the workflow. ##### RESULT For the measured collection workflow, API/network requests fell by 32.3× and execution improved by 2×–7×, with larger collections showing the greater improvement. ### 02 — Virtualizing Large Collections **ID:** virtualization **Domain:** Frontend Performance Built a custom lightweight React virtualization layer that decoupled mounted UI work from logical collection size. At roughly 3,300 items, the measured workflow kept about 27× fewer items mounted simultaneously, with the reduction ratio increasing as the collection grew. **Type:** Frontend performance - **Concerns:** DOM pressure, rendering cost, scroll responsiveness, supply-chain risk - **Stack:** TypeScript, React #### Metrics - **≈27×** — FEWER SIMULTANEOUSLY MOUNTED ITEMS #### Engineering reasoning ##### CONTEXT Large collection views could contain roughly 3,300 logical items, while only a small portion of the collection needed to be represented in the mounted UI at any given time. ##### PROBLEM Eagerly mounting the full collection made React and DOM cost grow with collection size. Reconciliation, layout, paint, memory use, and interaction pressure all increased even for content that was not immediately relevant to the user. ##### CONSTRAINTS Preserve the complete logical collection and expected scrolling behavior, keep the mounted render surface bounded, and avoid introducing an additional runtime dependency where supply-chain exposure mattered. ##### DECISION Build a lightweight feature-owned virtualization layer that separates the size of the logical collection from the amount of UI work mounted at any moment. ##### TRADE-OFF Owning the virtualization behavior reduced dependency surface and gave tighter control over the rendering boundary, but it also moved responsibility for correctness, scrolling behavior, edge conditions, and long-term maintenance into the application. ##### RESULT At roughly 3,300 logical items, the measured workflow kept about 27× fewer items mounted simultaneously than eager rendering. Because mounted work remained bounded while the logical collection continued to grow, the reduction ratio increased with collection size. ### 03 — Deterministic Processing Through Structural Decomposition **ID:** deterministic-ai **Domain:** Deterministic Systems × AI Decomposed structurally variable inputs into smaller units, applying deterministic processing where structure could be resolved and heuristic handling where ambiguity remained. For specific data types, the resulting path outperformed Azure Document Intelligence. **Type:** Decision system - **Concerns:** structural decomposition, determinism, heuristic fallback #### Engineering reasoning ##### CONTEXT A structured-data workflow had to normalize complex source representations into a consistent downstream form. ##### PROBLEM The overall input did not follow one reliable structure. Different regions could behave differently, and a single deterministic strategy could not resolve every part consistently. ##### CONSTRAINTS The solution had to preserve correctness across structural variation, avoid making the entire workflow probabilistic, and keep predictable portions of the transformation reproducible and testable. ##### DECISION Decompose the input into smaller structural units, identify the units that could be handled deterministically, and apply explicit processing strategies to those regions. For the remaining ambiguous units, use heuristic handling rather than forcing deterministic assumptions where the structure was insufficient. ##### TRADE-OFF The approach required maintaining multiple processing strategies and deciding where deterministic guarantees ended and heuristic interpretation began, but it prevented uncertainty in one part of the input from making the entire transformation probabilistic. ##### RESULT For specific data types, the resulting deterministic-plus-heuristic processing path outperformed Azure Document Intelligence. ### 04 — Concurrency Without Global Serialization **ID:** concurrency **Domain:** Concurrency & Consistency Migrated legacy batch processing toward microservices with optimistic locking and Java atomic reference updaters, doubling throughput without data inconsistencies in the reported result. **Type:** Concurrent state processing - **Concerns:** throughput, consistency, contention, conflict handling - **Stack:** Java, Microservices #### Metrics - **2×** — MIGRATION THROUGHPUT #### Engineering reasoning ##### CONTEXT A legacy batch-processing system was migrated into a microservices architecture. ##### PROBLEM The migration needed higher throughput while preserving consistency during concurrent state updates. ##### DECISION Use optimistic locking and Java atomic reference updaters so conflicting state transitions can be handled without globally serializing all work. ##### RESULT The reported migration result doubled throughput without data inconsistencies. ### 05 — Preventing Invalid Workflow Cycles **ID:** workflow-validation **Domain:** Graph Validation Modeled workflow configurations as directed graphs and used depth-first search to detect invalid cycles before deployment, reducing runtime errors by 50%. **Type:** Workflow validation - **Concerns:** cycle detection, correctness, pre-deployment validation #### Metrics - **50%** — FEWER RUNTIME ERRORS #### Engineering reasoning ##### CONTEXT Workflow configurations expressed dependencies between steps and needed to be validated before they were allowed into the runtime path. ##### PROBLEM A cyclic dependency could create an invalid execution path that was expensive to discover only after deployment or during runtime. ##### DECISION Represent the configuration as a directed graph and use depth-first search to detect whether traversal re-enters an active path. ##### IMPLEMENTATION Validate the graph before deployment and reject configurations when DFS identifies a cycle, while allowing acyclic configurations to proceed. ##### RESULT Pre-deployment cycle detection reduced runtime errors by 50% for the workflow-validation system. ### 06 — Rejecting Invalid Matches Early **ID:** matching-pruning **Domain:** Matching Optimization Applied dynamic-programming heuristics and early invalidation to a real-time matching workflow, eliminating non-viable candidates before more server work was spent and doubling throughput. **Type:** Real-time matching - **Concerns:** candidate space, early invalidation, throughput, server work #### Metrics - **2×** — MATCHING THROUGHPUT #### Engineering reasoning ##### CONTEXT A real-time matching module evaluated candidate relationships under load and needed to keep the amount of useful work proportional to viable matches. ##### PROBLEM Invalid candidates consumed processing time even though they could not contribute to a valid match, increasing server work as the candidate space grew. ##### DECISION Structure the matching path around dynamic-programming heuristics and early invalidation so non-viable candidates are removed before the remaining matching work. ##### IMPLEMENTATION Narrow the candidate space as soon as partial matching state proves a candidate cannot produce a valid result, leaving the later stages to operate on a smaller viable set. ##### RESULT The matching module achieved 2× throughput while reducing server work. ### 07 — Making Constrained Allocation Practical **ID:** constrained-allocation **Domain:** Constrained Optimization Built a constraint-aware backtracking solver for resource allocation across skill, language, and workload requirements, rejecting infeasible branches early instead of exhaustively evaluating every possible assignment. **Type:** Constrained resource allocation - **Concerns:** combinatorial search, constraint satisfaction, latency, scalability #### Metrics - **ms** — NEAR-OPTIMAL ALLOCATION FOR HUNDREDS OF REQUESTS #### Engineering reasoning ##### CONTEXT Resource allocation had to account for skill set, language, workload, and concurrent demand while still returning useful assignments quickly. ##### PROBLEM Possible assignments form a combinatorial search space, so exhaustively evaluating every complete combination becomes increasingly impractical as requests and candidates grow. ##### DECISION Model allocation as a constrained search and use backtracking with early feasibility checks so a partial assignment stops expanding as soon as it cannot lead to a valid solution. ##### IMPLEMENTATION Apply constraints during the search rather than only after complete assignments are generated, preventing entire infeasible subtrees from being explored. ##### TRADE-OFF The search remains combinatorial in the worst case; practical performance depends on rejecting infeasible branches early rather than pretending the underlying search space disappears. ##### RESULT The solver produced near-optimal allocations in milliseconds for hundreds of concurrent requests. ### 08 — Efficient Permission State **ID:** authorization **Domain:** Authorization Replaced a MySQL JSON permission array with a 64-bit BIGINT mask, keeping persisted permission state at 8 bytes while supporting 64 permission flags and mapping directly to a Java long. **Type:** Access management - **Concerns:** state density, persistence, serialization, authorization #### Metrics - **UP TO ≈100×** — SMALLER PERSISTED PERMISSION STATE #### Engineering reasoning ##### CONTEXT Effective permissions were persisted in MySQL as a JSON array of permission-name strings and loaded into the application for authorization. ##### PROBLEM The JSON representation grew with permission count and permission-name length, increasing the amount of authorization state persisted and transferred for each user. ##### DECISION Encode the bounded permission vocabulary as a 64-bit mask stored in one MySQL BIGINT and mapped to a Java long, assigning one stable bit position to each permission. ##### IMPLEMENTATION For the illustrated 64-permission case, permission names averaging roughly 10 ASCII characters occupy about 901 bytes in MySQL's binary JSON representation: 1 byte for the top-level type, 4 bytes for the array header, 192 bytes for 64 value entries, and 704 bytes for 64 encoded 10-byte strings. The replacement BIGINT is 8 bytes, so 901 B / 8 B ≈ 113×; the UI rounds this to ≈100×. Exact JSON storage should be verified with JSON_STORAGE_SIZE(). The application can load the same 64-bit value into a Java long and evaluate all required permissions with (userMask & requiredMask) == requiredMask. ##### TRADE-OFF Bit positions become part of the persisted-data contract: assignments must remain stable, and removed permissions should keep their bit reserved unless stored masks are migrated. One 64-bit mask also sets a 64-permission capacity boundary; a larger vocabulary requires another mask or a representation change. MySQL SET can already encode up to 64 schema-defined members compactly, so the storage gain here specifically compares the previous JSON representation with BIGINT. ##### RESULT In the illustrated 64-permission case, persisted permission state falls from about 901 bytes of MySQL binary JSON to an 8-byte BIGINT: approximately 113× smaller by raw value size, presented as ≈100× in the UI. ### 09 — From Source to Running System **ID:** system-delivery **Domain:** System Delivery Automated infrastructure provisioning across cloud environments with Terraform, shortening deployment time by 40% in that workflow, alongside CI/CD, automated testing, and containerized delivery. **Type:** Delivery and infrastructure - **Concerns:** reproducibility, deployment, testing, runtime operations - **Stack:** Terraform, CI/CD, Docker, Kubernetes, Linux, AWS, Azure, Oracle Cloud #### Metrics - **40%** — SHORTER DEPLOYMENT TIME #### Engineering reasoning ##### CONTEXT Infrastructure provisioning covered AWS, Azure, and Oracle environments, alongside application delivery with containerized cloud deployment. ##### PROBLEM Manual environment configuration made delivery less repeatable and introduced avoidable configuration errors. ##### DECISION Provision environments with Terraform and support delivery with CI/CD, automated tests, Docker, Kubernetes, and Linux operations. ##### IMPLEMENTATION Delivery work also included asynchronous processing with RabbitMQ and Kafka where heavy workloads benefited from messaging. ##### RESULT The Terraform provisioning/deployment workflow reduced manual configuration errors and shortened deployment time by 40%. ## Research ### Turbojet Engine Parameter Identification **ID:** turbojet-parameter-identification Bachelor thesis work in Automation and Information Technology focused on identifying turbo-jet engine parameters, retained as the earliest system-modeling thread in the Selected Work narrative. **Type:** Research - **Concerns:** parameter identification, system modeling # Public links - Website: https://www.anis-messas.com - LINKEDIN: https://cz.linkedin.com/in/anis-messas-22a6ba177