# Selected Work | Anis Messas — Engineering Cases & Research Selected engineering work covering performance, deterministic systems and AI, concurrency, production algorithms, authorization, delivery, and earlier research. ## 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